acer

32490 Reputation

29 Badges

20 years, 7 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@sand15

It seems that OuterProductMatrix may be measurably faster than KroneckerProduct in the case of symbolic entries. For float[8] Vectors it's much closer.

nb. Switching the other of the arguments seems better than transposing either result.

The `.` variant ends up calling OuterProductMatrix, with a tiny extra bit of overhead to get there (and less flexibility w.r.t. transposing).

@Carl Love It appears to work in Maple 2019.2.1 onwards.

@Carl Love Indeed.

In my Answer I had mentioned that  evala(simplify(expr))  would produce -2/7 back in Maple 2022.2.

As Austin mentions, in Maple 2024.0  simplify(expr)  no longer throws an error (or crash).

I have deleted a duplicate of this Question's thread.

@nm A short variant on your suggestion,

   sort(X,key=(u->parse(String(u)[2..])));

@sand15 The OP has asked a similar question, before. 

The OP's attempt to interpolate this meagre 11x20 grid of data may be ill-judged, with data values that vary so much. The attempt at cubic interpolation may be a poor idea here, introducing large (in magnitude) negative swings that don't characterize the actual data supplied.

@nm Ronan's line,
    use RealDomain in (maple_sol:=solve(eqx,[x]))[] end use;
appears to have misled you.

All that does is this,
    maple_sol:=RealDomain:-solve(eqx,[x])[]

The use...end use mechanism is not a universal way to change the bindings or values of things not present in the input. That's not what it's for or how it works. It's not going to change the value of "solve" or anything else that's already explicitly part of the body of a Library procedure (like PDEtools:-Solve or its internals).

Your "update" portion's example involving,
    use RealDomain in (PDEtools:-Solve(eqx,x)) end use;
does not exhibit a bug.

restart;

pack := module() option package;
  export f := x -> sin(x);
end module:

 

f := x -> x^2:

g := proc(s) f(s); end proc:

 

pack:-f(4);

sin(4)

 

# There's no way this could/should
# produce pack:-f(4) = sin(4)

use pack in g(4) end use;

16

with(pack):

f(4);

sin(4)

# There's still no way this could/should
# produce pack:-f(4) = sin(4)

g(4);

16

Download use_misuse.mw

A bug report has been logged.

This looks to me like it might be an oversight, and I don't think that I prefer it. I've submitted a message of inquiry.

Also, I'm not sure I like this related new variant (even though simplify will turn (x^2)^(1/2) into abs(x) under the real assumption, and has done for ages, and that's fine).

kernelopts(version)

`Maple 2024.0, X86 64 LINUX, Mar 01 2024, Build ID 1794891`

`assuming`([simplify(sqrt(1+sin(x)))], [real])

2^(1/2)*abs(sin((1/4)*Pi+(1/2)*x))

Download simp_2024_ex0.mw

@Ronan I terminated the statement (that contained the procedure call) with a full colon.

That suppresses printing of the return value, as output.

The flavors of visual side-effect (here, tabulated display) is however unaffected by the statement terminator of the proc call. 

For fun, a variety of visual side-effects made during a procedure call.

vis_sd_eff.mw

The print and Tabulate can both display plots and 2D Math, while lprint, printf, userinfo, and WARNING show plaintext.

@Ronan Since your procedure is returning those same values in either case, you could also reducing duplication in the code, by doing,

 ...
 if prnt then
   DocumentTools:-Tabulate([columns,[qqf,q13,q24]],'width'=55);
 end if;
 return qqf,q13,q24;
 end proc:

(I didn't realize, before, that you wanted prnt to toggle-on the Tabulation.)


I'm sorry, I don't understand what you mean about "...a double printing of qqf,q13,q24". I don't see what you think might induce that.

If you add another Reply to that previous thread then it'll get bumped to the top of the "recent" chain, which makes it more noticable.

Deleting the previous Question, to which Edgardo had responded, seems counter-productive (and not great etiquette, IMO).

@Carl Love Your claim is no longer true about the (now) default adaptive=geometric algorithm of the plot command.

And that is the case in both Maple 2023 and Maple 2024.

We can see that this is true because in the OP's Question the attached first plot looks good.

In fact we can run this example (in Maple 2024 with the gridline-coloring option, or in Maple 2023 without it), and demonstrate that the plot command's default/geometric adaptive scheme does in fact sample more at the lower end here, purely because the mode=log option was supplied for the axis.

restart

with(plots)

k := .9787011+(-10.88627-.9787011)/(1+(x/(0.4490702e-3))^1.792529)^.3004597

.9787011-11.8649711/(1+1001898.702*x^1.792529)^.3004597

P := plot(k, x = 10 .. 0.1e7, view = [10 .. 0.1e7, .92 .. .99], color = "Blue", adaptive = true, background = "Ivory", filled = [color = "Cyan", transparency = .9], size = [600, 300])

plots:-display(P, axis[1] = [mode = log])

plot(k, x = 10 .. 0.1e7, view = [10 .. 0.1e7, .92 .. .99], color = "Blue", background = "Ivory", filled = [color = "Cyan", transparency = .9], axis = [mode = log], size = [600, 300])

 

Download plot_geom_log_mode.mw

Yes, plots:-semilogplot is a perfectly fine workaround. But your claim is no longer true that axis= [mode= log] doesn't trigger the regular plot command to sample up front with logarithmic spacing. It does, here.

What happened in Maple2023 for the OP's example is that passing the additional gridline-coloring option broke the code that figured this out.

Your claim is true of the older non-default adaptive=true scheme.

First 49 50 51 52 53 54 55 Last Page 51 of 594