1638 Reputation

19 Badges

4 years, 79 days

MaplePrimes Activity

These are replies submitted by C_R

@Preben Alsholm 

Thank you for both informations.
The first is something I have probably overlooked on the functional operator help page. Maybe it is what the last bullet point want's to adress.

The second is very interesting. It looks to me like the if help page has been updated and now `if` is no longer easy to find (for whatever reason). Kind of a regression.

@Preben Alsholm 

I changed for clarity to ifelse and for the fact that `if` is not searchable in Maple 2023 help system. I could not check for versions that old.

I assume that older versions do not issue the warning about local declaration of i (which I could not turn off in the function definition).

but not really better because it is less clear what the code does.

f:= k -> add({seq(ifelse(floor(k/i)=k/i,i,0),i=1..k-1)});

The snippet above creates the set of divisors and adds them up. 

If you are more interested in other ways than in sharing consider asking a question. (A moderator can convert your post to a question if you want).


Thank you for the workaround. In the meantime I found annother case where I get an emtpy plot. I will make a software change request that Maplesoft can have a closer look (and use pointplot to keep the units).


Reading your explanations, I was wondering whether the int option “continuous” could have a positive effect on the computation time in cases where Maple invests time in analyzing expressions for discontinuities. I rather see the opposite on my original plot statement (this time without evalf): 

int(1/2*erf(1/2*sqrt(r__mx^2 - x^2)*sqrt(2)/sigma)*exp(-1/2*x^2/sigma^2)*sqrt(2)/(sqrt(Pi)*sigma), x = -r__mx .. r__mx);
int(op(%), continuous = true);
CodeTools:-Usage(plot(subs(sigma = 1, %), r__mx = 0 .. 10, numpoints = 10));

If I could ask a follow-up question, why don't equivalent integrals with units plot in the attachment below?



Thank you! Is there an explanation why, inside a plot statement, the normal way of evalf(Int(...)) did not work?


Thank you for the background. I take this as "a probably not possible" by standard methods even for the simple looking integral.

I will go numeric.

You can find here a discussion on solving PDE's and a very nice video from R. J. Lopez on the topic. 

There is also an ebook that has a chapter on solving PDEs with Maple.

Would a pulley with slippage (i.e. with friction) and cable componets (see below) be sufficient to model the hole-cable contact? 
If not, please provide more details on the hole-cable contact.


What does the newly introcuded print layout mode show? Is it also much too big?

Can you clarify print to pdf Maple and print ot pdf Wor.d? I do not have those.

Can you provide an example worksheet?


  • I cannot reproduce the error (see the attachment) with Maple 2022.2. What do you use?
  • You assume the upper bound of the integral smaller than the lower bound. Is that what you want?
  • evalf introduces numerical inaccuracies which can prevent simplification of expressions. It should be used after simplification but not before
  • Maple assumes that the other indeterminants zeta, kappa, m, mu, p are complex if not otherwise assumed. I have doubts that there is a solution. Maybe in the real domain.




Very helpfull for fine tuning. Thank you!

After forcing (via the Nvidia control panel) an exclusive use of the internal intel graphic processor for Maple and MapleSim the error was gone.

When the startup problem appeared again (startup termination looked a bit different) a “reset” of 3d-settings of the graphic card to “OS manages the graphic processors” solved the problem.

(To the best of my knowledge the graphic card settings where never modified by a user action.)


@ Moderators: Can you make this anwser a reply and anwser this question as beeing answered to remove it from the list of unanswered questions?


An example in the help page with arguments would have been helpfull. Your statement is also simpler than:

subsindets(expr, with_unit, z->convert(z,unit_free) );



With Maple 2022 latest improvements its very unlikely that units are wrong in plots unless labels with units are manually entered or useunits is used. Your alternative is like driving a car without safey belts. Once you get used to it you start feeling unsafe. In this particular case useunits works only partially

Unit(('W')/'m'^2)*max(t/Unit('s'), 0);
plot(%, t = -Unit('s') .. 2*Unit('s'), useunits = [ms, mW/mm^2]);

which is a new type of use error not possible before.

PS.: I should have expanded a bit more why I am interest in using max/min. It's a simple way of clipping the amplitude. Piecewise can become complicated. It looks to me that plot does not recognize that the max statement in my original expression is unitfree dimensionless and strips of all units when it encouters functions like max

Unit(('W')/'m'^2)*max(t, 0);
plot(%, t = -Unit('s') .. 2*Unit('s'));

that would otherwise return unevaluated as

max(W/m^2, 0)

There are probably more cases with a similar behavior. I was hoping for a kind of uneval trick that would make plot  throw an error (prevent stripping of all units) if statements are used that do not evaluate numerically.

1 2 3 4 5 6 7 Last Page 1 of 30