Perhaps it is not obvious and should be mentioned: the suggested method doesn't just affect the display of the names, but rather it creates something quite distinct. Sometimes that might be wanted, and sometimes not. The same goes for colouring it red, say, via Typesetting.

> t:=x->Typesetting:-mi(x, family = "Times", size = "18"):

> X := map(t, {A, B, C}):

> X intersect {A, B, C};
                                  {}

Now, the suggestion (which may well be exactly what Alex needs) doesn't just change the display programmatically. It creates distinct variables which do not interact as equivalent with the "normally" displayed names. I see that as a significant limitation.

acer

Perhaps it is not obvious and should be mentioned: the suggested method doesn't just affect the display of the names, but rather it creates something quite distinct. Sometimes that might be wanted, and sometimes not. The same goes for colouring it red, say, via Typesetting.

> t:=x->Typesetting:-mi(x, family = "Times", size = "18"):

> X := map(t, {A, B, C}):

> X intersect {A, B, C};
                                  {}

Now, the suggestion (which may well be exactly what Alex needs) doesn't just change the display programmatically. It creates distinct variables which do not interact as equivalent with the "normally" displayed names. I see that as a significant limitation.

acer

> R := Matrix([[cos(b/10),sin(b/10)]]);
                              [     b            b   ]
                         R := [cos(----)    sin(----)]
                              [     10           10  ]
 
> eval(R,b=evalf(Pi));
                        [0.9510565163    0.3090169944]
 
> evalf(eval(R,b=Pi));
                        [0.9510565163    0.3090169944]
 
> map(convert,eval(R,b=Pi),radical);
                     [ 1/2       1/2 1/2             1/2]
                     [2    (5 + 5   )               5   ]
                     [------------------    - 1/4 + ----]
                     [        4                      4  ]

acer

> R := Matrix([[cos(b/10),sin(b/10)]]);
                              [     b            b   ]
                         R := [cos(----)    sin(----)]
                              [     10           10  ]
 
> eval(R,b=evalf(Pi));
                        [0.9510565163    0.3090169944]
 
> evalf(eval(R,b=Pi));
                        [0.9510565163    0.3090169944]
 
> map(convert,eval(R,b=Pi),radical);
                     [ 1/2       1/2 1/2             1/2]
                     [2    (5 + 5   )               5   ]
                     [------------------    - 1/4 + ----]
                     [        4                      4  ]

acer

It is easy enough to see that randomize itself simply calls SetState from the MersenneTwister submodule of RandomTools.

interface(verboseproc=3):
eval(randomize);

acer

It is easy enough to see that randomize itself simply calls SetState from the MersenneTwister submodule of RandomTools.

interface(verboseproc=3):
eval(randomize);

acer

Yes, for floating-point Matrices use the LinearAlgebra package's commands Eigenvectors, NullSpace and Rank to compute the eigenvalues, nullspace, and rank. Those routines should use appropriate methods.

The underlying issues are not specific to Maple. See here for an explanation related to computation of the nullspace, for example.

acer

Yes, for floating-point Matrices use the LinearAlgebra package's commands Eigenvectors, NullSpace and Rank to compute the eigenvalues, nullspace, and rank. Those routines should use appropriate methods.

The underlying issues are not specific to Maple. See here for an explanation related to computation of the nullspace, for example.

acer

Student:-Calculus1:-Roots does in fact use fsolve with the avoid option. (But it uses it cleverly and repeatedly, until it ascertains that no more roots are in each generated subinterval.)

It's been for many years and Maple major releases that fsolve has, by default, returned only a single solution for the case of anything by a univariate polynomial. Changing that default would break a lot of users' code, so is a Bad Idea. Allowing it with some new syntax, such as fsolve(...,maxsols=all, <ranges>) might be ok.

Student:-Calculus1:-Roots is not bad, but one can write a 20 line procedure that is measurably faster, using RootFinding:-NextZero. You might also try the routine from Robert Israel's Maple Advisor Database which computes all real roots on a finite range.

acer

Student:-Calculus1:-Roots does in fact use fsolve with the avoid option. (But it uses it cleverly and repeatedly, until it ascertains that no more roots are in each generated subinterval.)

It's been for many years and Maple major releases that fsolve has, by default, returned only a single solution for the case of anything by a univariate polynomial. Changing that default would break a lot of users' code, so is a Bad Idea. Allowing it with some new syntax, such as fsolve(...,maxsols=all, <ranges>) might be ok.

Student:-Calculus1:-Roots is not bad, but one can write a 20 line procedure that is measurably faster, using RootFinding:-NextZero. You might also try the routine from Robert Israel's Maple Advisor Database which computes all real roots on a finite range.

acer

> ArrayTools:-RandomArray(1,2);
                [0.959492426392902997    0.792207329559554418]
 
> rtable(1..2,random(1..50));
                                    [9, 47]
 
> S := Statistics:-RandomVariable(DiscreteUniform(1, 50)):
> Statistics:-Sample(S,2);
                                   [2., 43.]
 
> LinearAlgebra:-RandomMatrix(1,2,generator=1..50);
                                  [37    48]
 
> Array(1..2,RandomTools:-Generate(list(integer(range=1..50),2)));
                                    [28, 7]
 
> Array(1..2,RandomTools:-Generate(integer(range=1..50),makeproc=true));
                                    [3, 14]

acer

> ArrayTools:-RandomArray(1,2);
                [0.959492426392902997    0.792207329559554418]
 
> rtable(1..2,random(1..50));
                                    [9, 47]
 
> S := Statistics:-RandomVariable(DiscreteUniform(1, 50)):
> Statistics:-Sample(S,2);
                                   [2., 43.]
 
> LinearAlgebra:-RandomMatrix(1,2,generator=1..50);
                                  [37    48]
 
> Array(1..2,RandomTools:-Generate(list(integer(range=1..50),2)));
                                    [28, 7]
 
> Array(1..2,RandomTools:-Generate(integer(range=1..50),makeproc=true));
                                    [3, 14]

acer

It seems that the Online Help is somewhat broken with respect to searches for topics containing an underscore.

For example, searching failed to find the page on special evaluation rules, even when either the partial "spec" or the full help-topic "spec_eval_rules" were tried. (One strange aspect here was that the unrelated last_name_eval did come up in the results, and that even has underscores in it.)

Another example was for convert/unit_free. Searching for "unit_free", or "convert/unit_free", or "convert,unit_free" all failed. (There appears to be a link to convert/unit_free at the bottom of the convert/units page. But it is broken, pointing at the invalid Convert/unit_free.)

acer

The difference is that add has special evaluation rules while sum does not.

One can fake it, with sum, by judicious use of uneval quotes (right-single-quotes).

> test2 := j->seq(x[j-i mod 24], i = 0 .. 8):
> test2(3);
           x[3], x[2], x[1], x[0], x[23], x[22], x[21], x[20], x[19]
 
> test := j->sum(x['j-i mod 24'], i = 0 .. 8):
> test(3);
       x[3] + x[2] + x[1] + x[0] + x[23] + x[22] + x[21] + x[20] + x[19]
 
> test := j->sum(x['`mod`'(j-i,24)], i = 0 .. 8):
> test(3);
       x[3] + x[2] + x[1] + x[0] + x[23] + x[22] + x[21] + x[20] + x[19]

When you used sum, it evaluated the arguments up front and worked with this,

> x[j-i mod 24];
                                  x[j + 23 i]
 
> seq(%, i = 0 .. 8);
x[j], x[j + 23], x[j + 46], x[j + 69], x[j + 92], x[j + 115], x[j + 138],
 
    x[j + 161], x[j + 184]

Since add has special evaluation rules, it can delay the application of mod until j and i have values.

acer

The difference is that add has special evaluation rules while sum does not.

One can fake it, with sum, by judicious use of uneval quotes (right-single-quotes).

> test2 := j->seq(x[j-i mod 24], i = 0 .. 8):
> test2(3);
           x[3], x[2], x[1], x[0], x[23], x[22], x[21], x[20], x[19]
 
> test := j->sum(x['j-i mod 24'], i = 0 .. 8):
> test(3);
       x[3] + x[2] + x[1] + x[0] + x[23] + x[22] + x[21] + x[20] + x[19]
 
> test := j->sum(x['`mod`'(j-i,24)], i = 0 .. 8):
> test(3);
       x[3] + x[2] + x[1] + x[0] + x[23] + x[22] + x[21] + x[20] + x[19]

When you used sum, it evaluated the arguments up front and worked with this,

> x[j-i mod 24];
                                  x[j + 23 i]
 
> seq(%, i = 0 .. 8);
x[j], x[j + 23], x[j + 46], x[j + 69], x[j + 92], x[j + 115], x[j + 138],
 
    x[j + 161], x[j + 184]

Since add has special evaluation rules, it can delay the application of mod until j and i have values.

acer