You have obtained only an equation by entering,

      RET = 8.364128*10^(-4); 

That is not the same as performing an assignment to RET by entering,

      RET := 8.364128*10^(-4); 

Note the colon-equals (:=) instead of just equals (=).

acer

You have obtained only an equation by entering,

      RET = 8.364128*10^(-4); 

That is not the same as performing an assignment to RET by entering,

      RET := 8.364128*10^(-4); 

Note the colon-equals (:=) instead of just equals (=).

acer

It appears that PolynomialInterpolation doesn't like it when one mixes the types of the data arguments. In this case, you had d as a list and w as an Array. It works if they are made to be the same (either Vector, list, or 1x20 Array)

CurveFitting:-PolynomialInterpolation(Vector(d),Vector(w), x);

CurveFitting:-PolynomialInterpolation(Array(1..20,d),w, x);

CurveFitting:-PolynomialInterpolation(d,convert(w,list), x);

acer

It appears that PolynomialInterpolation doesn't like it when one mixes the types of the data arguments. In this case, you had d as a list and w as an Array. It works if they are made to be the same (either Vector, list, or 1x20 Array)

CurveFitting:-PolynomialInterpolation(Vector(d),Vector(w), x);

CurveFitting:-PolynomialInterpolation(Array(1..20,d),w, x);

CurveFitting:-PolynomialInterpolation(d,convert(w,list), x);

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

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