Carl Love

Carl Love

20238 Reputation

24 Badges

8 years, 102 days
Mt Laurel, New Jersey, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@wswain You wrote:

  • The original array elements were of a text(string) type, ...

Yes, that's correct.

  • ... but you use subsindets to "transform" the list elements to string. 

No, that's incorrect. The second argument to subsindetsstring in this case, tells the command to look for objects of type string in its first argument, the list. Hence, the list must already contain strings for this to work.

  • Can you explain the "transformer" and "rest" arguments ...

The "rest" argument is not used in this example. If it had been used, it would be a constant (often an option) that would be the fourth argument of subsindets and passed as the second argument to the transformer.

  • ... how you know a valid transformer operator (in this case 'string') ,,,

You mean operand, not "operator". The subsindets command only passes to the transformer objects of the correct type, string in this case, specified in its second argument.

  • ...  vs it just acting on the elements?

Indeed, subsindets is overkill in this flat, linear case. It could be replaced (in Maple 2018 or later I believe) by

map(index, [seq](Array3[1, 2..]), [5..])

  •  I presume a different substring operation could have been used to remove chars 1-4 ?

No, u-> u[5..] is precisely the substring operation that does remove characters 1-4.

The Answers by Tom and acer show that some relatively minor bug related to your specific Question was fixed by Maple 2016. However, the more-important bug, the operator precedence itself, was not fixed until Maple 2020 (I think at my request). Here's proof:

kernelopts(version);
  Maple 2019.2, X86 64 WINDOWS, Nov 26 2019, Build ID 1435526
a %* b %+ c %* d;
                     %*(%+(%*(a, b), c), d)
kernelopts(version);
  Maple 2020.1, X86 64 WINDOWS, Jul 30 2020, Build ID 1482634
a %* b %+ c %* d;
                     %+(%*(a, b), %*(c, d))

 

@Madhukesh J K At the moment, I think that you'll learn more by trying to follow written directions rather than an explicit code example. If you try this, and it doesn't work, please post an executed worksheet showing your attempt, and I'll give you a code example.

First, do you know what a coefficient is? And do you know what a nonlinear term in a differential equation is? If you're not sure about either of these, please ask. Otherwise, here are the explicit and simple steps:

  1. Make C a coefficient of every nonlinear term in all 4 ODEs. In other words, multiply each such term by C.
  2. Add option continuation= C to the dsolve command. 

That's all there is to it.

 

@Wilks You have taken a very easy problem and made it enormously complex. Like I said from the start, there's no need to use solve. Like I said after you provided details, there's no need to use int or intat. All that can be replaced by dsolve.

You need to put restart at the beginning of your worksheet.

The entire "chapter" of your worksheet entitled INTEGRACIÓ EQ. DE L'ELÀSTICA (LLEI DE DESPLAÇMENTS) can be replaced by these few lines of code, which computes all 8 Ys at once:

for Y in {Y||(1..8)} do
    unassign(Y); #just in case
    assign(
        Y= unapply(
            (rhs@dsolve)
                ({diff(Y(x), x$2) = cat(Y,`"`)(x), Y(0)=0, D(Y)(0)=0}),
            x
        )
    )
od:

That's if you want the Ys without the symbolic constants of integration. If you do want the constants, it can still be done with dsolve; let me know. It seems like you want the same Y's to have the constants in one part of the worksheet but not the other. Just use different names to distinguish them!

@David Sycamore Given any list of [p,q] pairs (such as is generated by Kitonum's or my procedure), the sequence of just p can be extracted as Pseq:= op~(1, L)[]. The efficiency that can be gained by not storing the q in the first place is minimal.

@nm Time has been measured in minutes, so your last number should be "a little over 1/2 a minute". Otherwise, Vote Up.

@manju It wasn't me who posted that. However, that would be part of a command that sets all variables other than x and y in expression U to 1. The first part of the command would be eval(U, ...).

@mmcdara Yes, thanks for spotting that. I meant f(5). My error was the result of copying-and-pasting the old code and editing it (as is often the case with my posted errors). I'll correct the Reply above.

Type appliable is more general than type procedure, but it's often too-much-more general.

@Maple_lover1 Okay, my next guess is that the numbers that become strings are stored by Excel in some non-numeric format. If that is the case, the underlying issue cannot be addressed from the Maple side; however, it can be ameliorated by parse, as already shown.

@mmcdara Yes, I do prefer your "double-arrow procedure" method, and indeed I personally use that much more often than I use an indexed procedure.

So to apply this to the OP's situation:

div5:= proc(f) local x; unapply(f(x)/5, x) end proc:
f:= i-> x-> x^2+i:
div5(f(5));

Or, better yet, add some argument type checking, which isn't available for indexed procedures:

div5:= proc(f::appliable) local x; unapply(f(x)/5, x) end proc:
f:= (i::algebraic)-> (x::algebraic)-> x^2+i:
div5(f(5));

I see that the OP is using 2D Input. If instead they'd use 1D input (aka Maple Input), the 1st line could become (in Maple 2019 or later):

div5:= (f::appliable)-> local x; unapply(f(x)/5, x):

@Kitonum Thank you for catching my error.

But there's no way that having unapply inside piecewise will do what the OP wants. The return value must be a procedure.. Also, you should make local.

@gst I think there are some problems wih Kitonum's procedure. The unapply and piecewise should be switched and all the is should be ks. Try this:

divide5_new:= proc(g, k)
local x;
    if k::numeric then `if`(k<3, 0, unapply(g(k, x)/5, k, x))
    else unapply(piecewise(k<3, 0, g(k, x)/5), k, x) 
    fi
end proc:

 

@manju Why can't you see that the issues that you raise regarding this 3D plot are exactly the same as the issues you raised yesterday regarding a plot of differential equations? The solutions are exactly the same: Explorerand, etc.

@gst There's nothing fundamentally problematic with doing what you just said. The error that you had is simply due to attempting to evaluate the truth of i < 3 for symbolic i. You could instead write

if k::numeric and k < 3 then 0 else ... fi;

That would work fine.

@nm The majority of the code in my procedure above is to compensate for Matlab's weird argument order. The argument is optional; if it appears, it comes before the required argument Y. The sensible way to do it is to put optional arguments after required arguments.

What options are there other than the third argument, dim?

First 7 8 9 10 11 12 13 Last Page 9 of 569