@Ronan Yes, thanks for the interesting details. I've reread the prior responses now -- sorry about the Body2 attribution.

Please note that that the variant you cite (just above) from my Answer sheet attachment is quite inefficient (much more so than plottools:-rotate itself, which can turn lean float[8] rtable data into cumbersome listlists). I was really just trying to illustrate some other kinds of syntax would work for you (and in particular which allowed for Matrix `Rot` to be pushed in by name, say).

And with yet another way (somewhat of a cross bewteen my original and Rouben's).

equilibrium_alt2.mw

@Christopher2222There are more ways to rebind the name `changecoords` than just by loading the `plots` package. So your response is not wholly correct.

Using colon-dash before the name gets the global name, regardless. Wrap it in uneval quotes if you want something that guards against collision-with-a-local *and* assignment to the global, etc. 

Your last comment goes against the main thrust of your initial question.

Download elg_encrypt.mw

@Gibberish123 

@Christopher2222 

foobar := eval(:-changecoords)

@nk2016 

plots:-display(Array( [ [ P1, P2 ], [ P3, P4 ] ] ) );

@Gibberish123 The procedure rsa you show expects its second argument to be a list. So why are you trying to call it like rsa(26271227347, 11393739244) where the second argument is a scalar?

The fact that your function call to rsa returned unevaluated indicates that you have not actually made the assignment of the procedure you show (in an image, sigh) to the name rsa I suggest that you switch from 2D Input to 1D Maple Notation input, and from Document to Worksheet. See the GUI Options/Preferences.

Your procedure uses the name message. Where would that be defined? Your procedure has a parameter msg. Is the former a typo?

Your keys are very small.

Why do you ignore my suggestion to use the efficient syntax modp(Power(num,e), n) instead of the inefficient num^e mod n syntax?

Your technique of repeated list augmentation is inefficient. You could just use seq (or map) to operate over the elements of list msg, and have it be both more efficient and terse and understandable.

@Gibberish123 I don't understand why you want to do have argument msg be a list. And isn't `message` a typo for `msg`.

You seem to be ignoring everything I wrote before, as well as using several anachronistic maple programming syntax elements. It is hard to help when you don't respond directly to questions or suggestions.

Please don't repost this as yet another duplicate question, just because nobody has answered here. 

@Ronan No, there is a bug in plottools:-line that it works with unassigned names in the data. It should throw an error line `point` does. That's my opinions, anyway. Better is to delay evaluation, as I showed.

How about checking that dy/dx = 1/(-tan(t*(n+1)/n)) and consider when the denominator of that tends to zero? How often can that occur, given the bounds on t?

@vv Yes, I agree. I do not know offhand whether the following discrepancy is by design or oversight.

plottools:-line([0, 0, 0],[a,b,c]);
                   CURVES([[0., 0., 0.], [a, b, c]])

plottools:-point([a,b,c]);          
Error, (in plottools:-point) incorrect arguments for creating
 points structure, try providing the dimension option

plottools:-point([a,b,c],dimension=3);
Error, (in Plot:-Structure:-Points) points cannot be converted
 to floating-point values

@vv I gave three ways of doing it: using either unevaluation quotes, or the animate syntax (which splits command and its args), or both. Each of the three pairs (for line and point) have both calls being similar. No special difference as far as one (of the pair) goes versus the other,

I did this to contrast with your suggestion to use POINTS instead of point, which of course is indeed a special difference.

I suggest, therefore, that preventing premature evaluation (here, at least) by using uneval-quotes can work with a more consistent methodology than does replacement of command-name or use of internal structures. It's not alays true, but it is here, and often is.

@vv 
 

Download conver.mw

[edited] When I say, "not altogether clear why" I mean that `evala` may be looking for the dependence between the RootOfs, so as to return the result having just one as preferred. So perhaps it clarifies by doing it in steps, etc.

@tomleslie By using the combine(...,units) command first you can reduce both sides to common (canonical) units, before stripping them off as unit_free.

See my Answer below, from earlier today.

@Gibberish123 I don't understand what your last Comment is about, sorry.