I believe that this can be done, but not so easily.

If I understand you rightly, you want to symbolically generate formulae f in Maple as Maple language code, put that into a Maple procedure, then somehow get it compiled as C or Fortran, and then make the resulting object code accessible as function sub1 and callable by external function sub.

One way to go about it might be to use Maple's CodeGeneration[Fortran] or CodeGeneration[C] in order to emit the source code for sub1. Then compile and link that into a .dll (or .so on unix or OSX). Then amend the define_external link flags so that it picks up this .dll and links additionally against it when setting up define_external('sub'....). See the ?COMPILE_OPTIONS help-page for how to amend the link flags. Also, the compilation of the sub1 source and creation of its .dll could be automated using ssystem calls in Maple. There's quite a bit of effort here, but done properly this should all work and be reasonably efficient, I think.

Another approach could be to use a so-called callback to sub1 a Maple procedure. The callback from sub to sub1 coule be done by passing that Maple procedure as part of the external call. See the ?WRAPPER help-page for information about such callbacks. You might even use the Maple Compiler:-Compile routine to compile the Maple procedure sub1, to make it fast. (I do not know how much overhead there might be in such a scheme, due to conversion of scalar arguments to and from hardware and software floats as they pass between these layers.)

acer

It is possible to view the procedures used in the elements.

> with(ScientificConstants):

> interface(verboseproc=3):

> GetElement(17,'density');

> GetElement(1,'electronaffinity');

The ones that I've looked at so far make some sense.

Querying the electron affinity of hydrogen reports that one should query the isotropic property of either the H[1] or H[2] isotope instead (otherwise the question doesn't make unique sense). Asking for the density of chlorine make sense only in the gas sense (but will that always be so?). Some queries have straightforward answers and the data is stored simply, without procedures. If one follows instructions then any numeric values (in an appropriate subcontext) can be extracted.

It looks to me like a justified difference rather than a problematic discrepancy. Of course, one can always fill out the software change request.

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

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