Preben Alsholm

13516 Reputation

22 Badges

19 years, 142 days

MaplePrimes Activity

These are replies submitted by Preben Alsholm

@acer I find the same error in Maple 2022.2:


@mmcdara The error occurs also in Maple 2022.2, but NOT in Maple 2021.2.
Even in Maple 12 there is no problem although the denominator is slightly larger than the one in 2021.2.

@QM I deleted your answer as I deemed it quite inappropriate. You were "answering" your own question, which is OK in itself, but the content wasn't relevant to your own question to put it mildly.
Incidentally, I think this is the first time I have seen somebody select his own answer as the best.

@acer Thanks for pointing out my confusion. Thinking about limit and maximize at the same time must have confused me.

I ran your worksheet in Maple 2023.0.
I was puzzled by the output from the first example's convert/Diff that on my computer doesn't join the Diffs.
and therefore looks weird.
The same happened with the other convert/Diff examples.
Replacing all the Diff's in the worksheet with diff made the results look nice as it apparently does in your version of Maple.
This problem is also present in Maple 2022.2, but not in Maple 2021.2.
I shall submit an SCR.

@mmcdara Using your example we see another failure of maximize here:
NB: Forget about this, please. My mistake!

u := (1 + 20230321)*x*y - (x^2 + y^2)/2;
v := collect(eval(u, [x=lambda*cos(t), y=lambda*sin(t)]), lambda);
limit(vt,t=infinity); # OK: undefined
maximize(vt); # OK: Returns unevaluated
maximize(v);  # Not OK: Returns infinity
debug(minimize); # maximize(v) is basically defined as -minimize(-v)


I have set default zoom at 125%.
To do that go to Tools/Options/Interface/Default zoom and choose the zoom percentage you prefer.
Press the button Apply Globally below. You can always change it if you don't like what you have chosen.

@QM DirectSearch:-GlobalOptima does fine. It is a numerical program though.

u:=20230322*x*y - 1/2*x^2 - 1/2*y^2;

DirectSearch is available from the Maple Application Center for free.

Adding ranges helps.

maximize(u, x=-1..1, y=-1..1, location);

Obviously, the unrestricted u has no finite maximum:

eval(u,y=x) = 20230321*x^2.


I wasn't aware of your previous posting until acer pointed it out.
Now I realize that you already received answers from several highly competent people on the very same topic.

@sursumCorda I tried  besides the E result from yesterday in separate worksheets.
I used the same x and y as yesterday.
Here is the dollar code and also the results for both:

read "C:/Users/pkals/Desktop/tempxy.m";
x[1..10]; # Just a test

Edollar:=CodeTools:-Usage(f~(x,` $`,y),iterations=10):
# Edollar: memory used=0.62GiB, alloc change=1.21GiB, cpu time=42.60s, real time=10.48s, gc time=37.04s
# E:       memory used=0.62GiB, alloc change=0.96GiB, cpu time=42.25s, real time=9.81s, gc time=37.36s
# Yesterday: E: memory used=0.62GiB, alloc change=0.99GiB, cpu time=38.94s, real time=9.63s, gc time=34.31s

As I see it if there is a real difference then it's Edollar being worse.
In any case I can't conclude that the one is faster than the other.
In fact I think that before executing f~ the dollar is taken away somehow. Try this were a and b are just names:

f(a, ` $`,b); # No ~
f~(a, ` $`,b); # with ~


@sursumCorda  Yes, I did a test consisting in first generating x and y. Then saving them to my Desktop as an .m file.

My Maple is set up to use a new engine for every worksheet.
So in two different worksheets I did elementwise (E) and zip (Z) separately.
Here is the E:

read "C:/Users/pkals/Desktop/tempxy.m";
x[1..10]; # Just a check
E alone: memory used=0.62GiB, alloc change=0.99GiB, cpu time=38.94s, real time=9.63s, gc time=34.31s

and here is Z:

read "C:/Users/pkals/Desktop/tempxy.m";
x[1..10]; # Just a check
# Z alone: memory used=0.62GiB, alloc change=0.96GiB, cpu time=44.97s, real time=11.24s, gc time=39.90s


Did you expect elementwise and zip to take the almost exact same time?
They don't look that way to me.
Your own results above don't look very different to me.
I tried myself:

x := combinat:-randperm(10^7):
y := combinat:-randperm(10^7):
# E: memory used=0.62GiB, alloc change=1.18GiB, cpu time=44.64s, real time=10.22s, gc time=39.70s
# Z: memory used=0.52GiB, alloc change=72.29MiB, cpu time=15.26s, real time=6.16s, gc time=10.58s
evalb(E=Z); #true

Incidentally to me your own results about elementwise and map don't appear wildly different either:

Surely the uses of map and `~` have some overlap.
But their respective domains of operation are different.
Here are two examples where `~` doesn't work:

map(simplify,sqrt(a^2)+sqrt(b^2)) assuming a>0,b<0;
f~([a,b],[a,b,c]); #error


@nm On purpose I didn't do that becase it won't have any effect in RootOF.
Notice this:

subs(_Z=ZZZZZ,{S4}); # The substitution is made yes, but:
%; # back to _Z
RootOf(sin(x),x); # Look at the result

For more look at ?RootOf in particular the examples.

_Z is protected exactly because of its use here:
Try assigning to _Z as in _Z:=1234;
Also try:

local _Z;

Notice the global version :-_Z in RootOf

First 8 9 10 11 12 13 14 Last Page 10 of 226