acer

32348 Reputation

29 Badges

19 years, 329 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

A callback (PROC) argument to define_external is only supported if the 'WRAPPER' option is also supplied, as far as I know. And the 'WRAPPER' option specifies that Maple will produce and compile a "wrapper" source file on-the-fly. (When external calling was introduced in Maple 6, that was its only mode of operation. Since then "wrapperless" external calling has been made possible using new libs maplec.dll or maplefortran.dll. But that mode doesn't support PROC.)

So, to use callbacks one must use WRAPPER, you are right. And to use WRAPPER one must have a compiler. Normally I'd say look at the free Watcom C compiler that comes bundled with Maple (and used by Compiler:-Compile). If that didn't work automagically for wrapper-generating define_external calls then one could likely set it up. See the ?COMPILE_OPTIONS help-page which seems to mention WATCOM already. But, your principal code is in Fortran.

I don't know whether the WRAPPER and FORTRAN options are supported simultaneously. (The error message you got mentioned maplec.lib which is curious.) And that seems to be key for you. If it doesn't then there may still be a way by writing and compile a custom wrapper in C (?CustomWrapper) and forming a .dll of that by hand, in advance.

Even if one worked in pure C this task seems complicated. But it may be a natural request or enhancement: Compile a Maple procedure, and then somehow pass its address to a precompiled external library of user-defined functions. (Eg, given a premade external library for global optimization or quadrature, compile the objective or integrand -- prototyped in Maple -- using Compiler:-Compile and then pass that to the external routines via define_external.)

acer

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

First 487 488 489 490 491 492 493 Last Page 489 of 592