acer

32662 Reputation

29 Badges

20 years, 67 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@WD0HHU To avoid GUI sluggishness sand15 has suppressed the final display call (terminating the line with a full colon) and then manually inserted an image of the plot (eg. from a file, etc).

So you could manually deleted that inserted imade, change to a semicolor for the final line, and then execute.

You can play with the various cases, the size (vs say the constrained scaling), the end values for the contours, and adjust according to which region needs the finer grid the most.

plot-help_sand15_ac24_r.mw

I've often mentally relied on the general notion that specifying a specific class of simplification (trig, exp, radical, power, etc) to the simplify command would prevent it from doing simplifications from the other classes.

But the conversion from form (x^2)^(1/2) to csgn(x)*x is manipulation of a radical. I dislike the fact that can happen even when the trig option is forced. Maybe it's a bug.

simplify( sqrt(z^2) );

csgn(z)*z

simplify( sqrt(cos(z)^2), trig ); # OK

(cos(z)^2)^(1/2)

simplify( 1-sin(z)^2, trig );

cos(z)^2

simplify( sqrt(1-sin(z)^2), trig ); # ooof

csgn(cos(z))*cos(z)

I would like to mention that the OP did not ask about merely how to replace all instances of cos(x)^2 with 1-sin(x)^2.

Doing that simple substitution is indeed straightforward, with several ways to accomplish it. That's true even if you code it for arbitrary names/subexpressions rather than just `x`.

Rather, the OP asked about how to simplify sqrt(1-cos(x)^2) to sqrt(sin(x)^2). That implies that the OP considers the latter to be simpler. And I suspect that stems from its having fewer terms (with the same class of elementary call), etc, and not because it has sin rather than cos, and so on.

So it doesn't seem (to me) to be in the spirit of the OP's request to have an approach that would also change any and all individual cos(...)^2 calls into the sums like 1-sin(...)^2 .

And the OP is very likely to have more complicated expressions, perhaps in terms of other variable names, etc. So examining the expressions for which have standalone -cos(v)^2 as opposed to 1-cos(v)^2 isn't in the vein of such programmatic simplification.

The following change (which might occur anywhere in some larger expression of the OP) might not be the kind of blanket efftect that the OP wants:

expr := sqrt(cos(x)^2);

(cos(x)^2)^(1/2)

simplify(expr, {1-cos(x)^2=sin(x)^2});

(-sin(x)^2+1)^(1/2)

algsubs(1-cos(x)^2=sin(x)^2, expr);

(-sin(x)^2+1)^(1/2)


ps. I'm not saying that I agree that shortness is a key thing to being simple here. But it might be, for some people.

Also, there are some tricky issues lurking about. Maple prefers cos to sin, in some cases. We could consider how to avoid turning standalone cos(v)^2 into the longer 1-sin(v)^2 , which also being able to turn (with generic variable names),
    2-cos(x)^2 - cos(y)^2
into,
     sin(x)^2 + sin(y)^2

Here's some idiosyncratic behavior:

restart;

simplify( 1 - cos(x)^2 );

sin(x)^2

I'm hoping now to get sin(x)^2+sin(y)^2

simplify( 1 - cos(x)^2 + sin(y)^2 );

-cos(y)^2+2-cos(x)^2

restart;

simplify( 1 - sin(x)^2 );

cos(x)^2

Oh, sure, the other ways works, because Maple
likes cos ...

simplify( 1 - sin(x)^2 + cos(y)^2 );

cos(x)^2+cos(y)^2

@WD0HHU 

You could try the following,

plot-help_sand15_ac24.mw

I replaced,
   acore := expand(abs(core)) assuming y::real, z::real:
by,
   acore := abs(expand(core)) assuming y::real, z::real:

AFAIK there has never been any technical reason why one cannot install multiple instances of the same major version number of Maple on the same machine.

I haven't yet tested it on Maple 2025, but I've done this previously on Linux with all versions (all update point-releases) from Maple 6 through to Maple 2024.  And for MS-Windows I did it for all versions (all update point-releases) from Maple 6 through to Maple 2020.

The main thing to do is to install them in their own separate folders/directories/locations.

For the Windows desktop you could give the various launcher icons different labels.

Naturally, it's necessary that your activation key will still work for each install. You could contact Tech Support, if the number of activations is "all done" for your key. They might be able to accomodate you, if it is.

@JP Howe There are a few alternatives to the palette, for entering expressions containing units.

One way to do that is to enter units within the Unit command, eg. Units(kg).

Or, if you'd still like to have your units nicely typeset in your 2D Input you could use command-completion. For example, if your type the first few part of that, say,
    Unit
you could then enter command-completion mode, and choose the unit constructor as one of the top items in the combo-box menu that pops up.

Several of the key things to know are absent in just your images of a session.

For one thing, we cannot deduce which version your using -- since you haven't set the "Product" field in your Question with the version number.

Also, we cannot know what code might have occurred before your pasted images.

And we don't know what packages your session might have loaded. And we don't know what values might have been assigned to the names you're using.

Also, we cannot tell whether you're using units properly. That is, "kg" appears in italics, so have you used merely the name kg rather than Unit(kg)? We cannot tell for sure.

You can upload and attach a .mw worksheet document, and inline either its content or just a download link, using the green up-arrow in the Mapleprimes Question editor's toolbar.

@sand15 I voted up.

What do you think about putting option remember on the ANS procedure; see the attachment.

Generic_2d_plot_sand15_ac.mw

You can see the timing effect. Repeated inputs values of the plotting variable occur if the plotting range and the numpoints choices are repeated.

@WD0HHU This site doesn't has that problem, for files with names containing special characters like & (ampersand).

@nm Sorry, I'm having trouble reproducing my success now. I may have gotten confused with the filenames I was using with attempts in different interfaces.

It's an unfortunate bug.

Here are a few ideas:

Just as a check, does it also fail to produce those expected gridlines in the commandline-interface's exported image file if you use another format like bmp or gif?

What if you use the command,
    Export( .... )
instead of,
    plottools:-exportplot

I wonder whether this problem is specific to Windows. It seems to work OK for me in the commandline-interface on Linux. Is there a possibility that you could use the new Windows Subsytem for Linux (WSL), a runtime supported as a layer on MS-Windows? Even if you don't want to run your whole complicated scripting processes (I know they are large and involved) in this way you might be able to just save the plots and a filename string to .m format and then run a short Maple script in the Linux that read in the .m file and ran the plot export.

@JP Howe You didn't answer all my queries, no. Are you using MS-Windows? And Maple 2025.2?

I don't have that point-release version on that OS, but perhaps someone else here might be able to check whether it works for them. 

It works for me.

What Maple version are you using?

Do you see the rest of those code lines having their expected effects? If yes, then how are you checking whether the LinearAlgebra package got loaded? If no, then what is the explicit location of the initialization file that you're using?

@nznz1987 Carl provided his code as plaintext, ie. 1D Maple Notation code It seems as if you might have copy&pasted it in as 2D Input.

@Rouben Rostamian  I mentioned it in my Reply's last paragraph above. The curves coming out of usual contourplot calls are each made from a collection of small curves (ie. many CURVES substructures within the PLOT structure).

Even though these many CURVES each have linestyle=dash applied to them, they are (usually, by default) each too short for the GUI to render them clearly enough for us to be able to see the dashed effect.

This granularity of how the CURVES are produced is related to the grid size with which the internals compute and construct it all. If you also pass, say, grid=[6,6] to contourplot then you can usually also see the linestyle's effect, because then these individual segments are longer. But then the resulting level-curve contour lines are too coarse and chunky.

plots:-contourplot(x^2-y^2, x=-1..1, y=-1..1,
                   grid=[6,6], linestyle=dash);

Sometimes one can programmatically meld together the CURVES substructures that pertain to a longer, single, rendered curve. But it's effort.

So (often) a possible alternative is to make separate implicitplot calls, for each contour value, and give those the linestyle.

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