Hi Jacques, I don't really understand the rules. Is it forbidden, in this first stage, to recreate Library routines? And if it is forbidden to recreate them, then is it only forbidden to call proc()? Ie, is this example below forbidden? libname := "": f := eval(eval): f := subsop(3=NULL,eval(f)): f := subs(118='iolib(28,args)',eval(f)): f := subsop(3=`Copyright (c) 1994-1998 by Waterloo Maple Inc. All rights reserved.`,eval(f)): f := subsop(5=`Fetches the value of a system environment variable.`,eval(f)): getenv(PWD); setattribute(getenv,[]): getenv := subs(X=X,eval(f)): f := 'f': getenv(PWD); streamcall(INTERFACE_SET(verboseproc,2)): eval(getenv); If I did that as I intended, then the above uses only built-in routines to create getenv(). But the result isn't any different from the Maple 10 Library routine getenv(), is it? So, is it forbidden to ever create and use any procedure that doesn't have option builtin as its first option? Are you going to forbid, at this stage, routines like fclose(), etc, which, while technically "1-functions", are the approved way to get at iolib()? Dave Linder Mathematical Software, Maplesoft

I'm glad that the context-menu (right-click) on final results to convert the units works for you. But perhaps you would like to see pressure shown with torrs by default, throughout your computations, without the extra conversion required. This can be done by defining and using a new system of units which is identical to SI except that torr is now the default unit for pressure. Normally, in the SI system, pascals is the default unit for pressure. Consider, restart: combine( 7*Unit(kg)/(Unit(m)*Unit(s)^2), units ); Units[AddSystem]( NewSI, Units[GetSystem](SI), torr ); Units[UseSystem]( NewSI ); combine( 7*Unit(kg)/(Unit(m)*Unit(s)^2), units ); So, after the above, pressure should get expressed with units of torrs. The Units package is very customizable. You can configure it to represent various dimensions in several sorts of useful ways. note: I did not load the Units package above by issuing with(Units); Instead I simply used two individual commands from that package directly. note: In your first post in this thread, you mentioned that when using the right-click context menu on, p := 1*Unit(atm) -> 1*Unit(torr) that p retained the unit atm. That is how context-menus work, by modifying the output. But doing so does not modify the left-hand side of the original assignment. You can verify this by doing, say, p := 1/3 -> 0.3333333333 with the right-click to do Approximate->10 from the context menu. Then query the value of p. It is still the exact rational 1/3, and not the floating-point approximation 0.3333333333. Dave Linder Mathematical Software, Maplesoft.

I'm glad that the context-menu (right-click) on final results to convert the units works for you. But perhaps you would like to see pressure shown with torrs by default, throughout your computations, without the extra conversion required. This can be done by defining and using a new system of units which is identical to SI except that torr is now the default unit for pressure. Normally, in the SI system, pascals is the default unit for pressure. Consider, restart: combine( 7*Unit(kg)/(Unit(m)*Unit(s)^2), units ); Units[AddSystem]( NewSI, Units[GetSystem](SI), torr ); Units[UseSystem]( NewSI ); combine( 7*Unit(kg)/(Unit(m)*Unit(s)^2), units ); So, after the above, pressure should get expressed with units of torrs. The Units package is very customizable. You can configure it to represent various dimensions in several sorts of useful ways. note: I did not load the Units package above by issuing with(Units); Instead I simply used two individual commands from that package directly. note: In your first post in this thread, you mentioned that when using the right-click context menu on, p := 1*Unit(atm) -> 1*Unit(torr) that p retained the unit atm. That is how context-menus work, by modifying the output. But doing so does not modify the left-hand side of the original assignment. You can verify this by doing, say, p := 1/3 -> 0.3333333333 with the right-click to do Approximate->10 from the context menu. Then query the value of p. It is still the exact rational 1/3, and not the floating-point approximation 0.3333333333. Dave Linder Mathematical Software, Maplesoft.

There are several ways to do stacking and augmenting of Matrices and Vectors, some of which might depend on the type of data. If you could supply some (small, but fully detailed) examples of what you are trying to accomplish then it would be easier to make suggestions as to efficient ways to do it. Another useful piece of information is whether you would be content with a result that contained only (possibly complex) floating-point data. Thanks very much, Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

The help-page ?Statistics,Beta mentions this. It says, "Note that the Beta(a, b) returns the value of the Beta function with parameters a and b, so in order to define a Beta random variable one should use the unevaluated name 'Beta'." The first two Examples in that help-page should illustrate the distinction, by showing the invalid form as well as an alternative. Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

Hi Fred, I believe that Axel's issue involves external-calling not being available from within evalhf. The evaluations of the integrand done during the Nag quadrature calls is currently only done by evalhf-callbacks to Maple. So, he is probably trying something like this: > g:=define_external('gsl_sf_bessel_K1', > 'r'::float[8],'RETURN'::float[8] , > LIB="libgsl.so"): > evalf(Int(g, 1..2, method = _d01ajc)); Error, (in evalf/int) unable to evaluate built-in function `call_external` in evalhf > # The above occurs due to this: > evalhf(g(1.2)); Error, unable to evaluate built-in function `call_external` in evalhf It might be better if the external wrapper which makes the callbacks to evaluate the integrand tried a software-float evalf-callback for certain types of evalhf-callback failure. With an evalf-callback, an external-call inside the integrand procedure would be possible. There might be wider benefits to this, as there are certain of Maple's own special functions which do not run under evalhf. Eg, > evalhf(BesselK(0,2)); Error, remember tables are not supported in evalhf > # I'm not a fan of that error message. But the gist is that > # it is not a function known to evalhf. > evalf(BesselK(0,2)); 0.1138938727 And here below we can see a numeric integration problem falling back to an alternate method, after failing in the Nag attempt due to the above. > infolevel[`evalf/int`]:=1: > evalf(Int(x->'BesselK'(0,x), 1..2)); Control: Entering NAGInt Control: trying d01ajc (nag_1d_quad_gen) Control: d01ajc failed evalf/int/control: NAG failed result = result evalf/int/control: "applying double-exponential method" evalhf mode unsuccessful -- retry in software floats evalf/int/quadexp: "applying double-exponential method" From quadexp, result = .2311658856921 integrand evals = 75 error = .2805320420795e-10 0.2311658857 The original rationale for evalhf-callbacks during the Nag quadrature calls was that evalf-callbacks were too slow in general. Unwanted translations from hardware to software to hardware floats added too much overhead. So, there are number of improvements that might be made: 1 - external-calling under evalhf 2 - evalf-callbacks attempts during external quadrature, upon certain types of evalhf-callback failure 3 - addition of certain special functions into evalhf's "runtime", possible using methodolgy from Tom R.'s thesis, or possibly as new code compiled in. Now, suppose that a single evalhf-callback failed. Some new flag would probably need be set, so that predictably failing evalhf-callbacks would not be attempted for each subsequent evaluation of the integrand. There likely are counter-examples, though, where subsequent evalhf-callbacks would work, and be fastest. And, when not in case that a forcing method option were supplied, evalf(Int()) would still be wanted to fallback to a fast alternative method. There likely are other examples where performance might be better using a completely different fallback method, rather than to retry with a Nag routine and software evalf-callbacks. So, getting overall best performance can be tricky. It would require investigation to determine what timelines might be involved with making any of the above improvements, and I'm not able to make statements about that at this time. cheers, Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

Hi Fred, I believe that Axel's issue involves external-calling not being available from within evalhf. The evaluations of the integrand done during the Nag quadrature calls is currently only done by evalhf-callbacks to Maple. So, he is probably trying something like this: > g:=define_external('gsl_sf_bessel_K1', > 'r'::float[8],'RETURN'::float[8] , > LIB="libgsl.so"): > evalf(Int(g, 1..2, method = _d01ajc)); Error, (in evalf/int) unable to evaluate built-in function `call_external` in evalhf > # The above occurs due to this: > evalhf(g(1.2)); Error, unable to evaluate built-in function `call_external` in evalhf It might be better if the external wrapper which makes the callbacks to evaluate the integrand tried a software-float evalf-callback for certain types of evalhf-callback failure. With an evalf-callback, an external-call inside the integrand procedure would be possible. There might be wider benefits to this, as there are certain of Maple's own special functions which do not run under evalhf. Eg, > evalhf(BesselK(0,2)); Error, remember tables are not supported in evalhf > # I'm not a fan of that error message. But the gist is that > # it is not a function known to evalhf. > evalf(BesselK(0,2)); 0.1138938727 And here below we can see a numeric integration problem falling back to an alternate method, after failing in the Nag attempt due to the above. > infolevel[`evalf/int`]:=1: > evalf(Int(x->'BesselK'(0,x), 1..2)); Control: Entering NAGInt Control: trying d01ajc (nag_1d_quad_gen) Control: d01ajc failed evalf/int/control: NAG failed result = result evalf/int/control: "applying double-exponential method" evalhf mode unsuccessful -- retry in software floats evalf/int/quadexp: "applying double-exponential method" From quadexp, result = .2311658856921 integrand evals = 75 error = .2805320420795e-10 0.2311658857 The original rationale for evalhf-callbacks during the Nag quadrature calls was that evalf-callbacks were too slow in general. Unwanted translations from hardware to software to hardware floats added too much overhead. So, there are number of improvements that might be made: 1 - external-calling under evalhf 2 - evalf-callbacks attempts during external quadrature, upon certain types of evalhf-callback failure 3 - addition of certain special functions into evalhf's "runtime", possible using methodolgy from Tom R.'s thesis, or possibly as new code compiled in. Now, suppose that a single evalhf-callback failed. Some new flag would probably need be set, so that predictably failing evalhf-callbacks would not be attempted for each subsequent evaluation of the integrand. There likely are counter-examples, though, where subsequent evalhf-callbacks would work, and be fastest. And, when not in case that a forcing method option were supplied, evalf(Int()) would still be wanted to fallback to a fast alternative method. There likely are other examples where performance might be better using a completely different fallback method, rather than to retry with a Nag routine and software evalf-callbacks. So, getting overall best performance can be tricky. It would require investigation to determine what timelines might be involved with making any of the above improvements, and I'm not able to make statements about that at this time. cheers, Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

I suppose that the responders have been having difficultly understanding precisely what you're after. Here's another possibility. T := proc(f,t) local mt; mt := eval(f(x)+add(Diff(f(x),x$i)*(X-x)^i/i!,i=1..5),x=t); subs(X=x,mt); end proc: T(sin,Pi); value(%); T(sin,x0); value(%); T(f,Pi); So, the results of T look like the general form, but if you wish you can still get the "solution". I hope that helps. Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

I suppose that the responders have been having difficultly understanding precisely what you're after. Here's another possibility. T := proc(f,t) local mt; mt := eval(f(x)+add(Diff(f(x),x$i)*(X-x)^i/i!,i=1..5),x=t); subs(X=x,mt); end proc: T(sin,Pi); value(%); T(sin,x0); value(%); T(f,Pi); So, the results of T look like the general form, but if you wish you can still get the "solution". I hope that helps. Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

Is this an example of the sort of thing you want? mtaylor(f(x),[x=Pi]); eval(%,f=sin); or perhaps, mtaylor(f(x),[x=Pi]); subs(f='sin',%); eval(%); or maybe even, mtaylor(f(x),[x=Pi]): MT := unapply(%,f); MT(sin); Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

Is this an example of the sort of thing you want? mtaylor(f(x),[x=Pi]); eval(%,f=sin); or perhaps, mtaylor(f(x),[x=Pi]); subs(f='sin',%); eval(%); or maybe even, mtaylor(f(x),[x=Pi]): MT := unapply(%,f); MT(sin); Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

Passing one error message that you received, "segment prot after reloc: Permission denied", to google gets quite a few hits. The issue seems to be quite commonly connected to SELinux and security permissions, and seems to affect a significant number of other software packages, eg. Matlab, Mathematica, OpenOffice, Oracle, etc. You might try issuing such a google search and studying some of the solutions given in links relating to this issue and other software. For example, http://sunsolve.sun.com/search/document.do?assetkey=1-25-83248 I don't have Fedora Core 4 (FC4) installed, but it's possible that disabling SELinux might suffice. It also might be the case that some security restriction could be eased for Maple's libmclient.so (and/or friends) while retaining security levels otherwise. So these links might be of interest, http://fedora.redhat.com/docs/selinux-faq-fc3/ http://fedora.redhat.com/docs/fedora-install-guide-en/fc4/sn-selinux.html Note that FC4 is not, at this time, an officially supported platform for Maple 10 or earlier. Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

I interpreted the original posting as a request for abstract linear algebra support in Maple. A similar request was posted a few days earlier. Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

I interpreted the original posting as a request for abstract linear algebra support in Maple. A similar request was posted a few days earlier. Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.

You could try to use RootFinding[Analytic] to obtain all the roots in a complex box, and then to select only the real roots from those results. For example, > eqn := x^4 + 5*x^3 + 4*x = sin(x): > sols := RootFinding[Analytic]( eqn, x=-10-1*I .. 10+1*I ): > select(x->type(x,realcons),simplify([sols])); [0., -5.156989371] > evalf[6](%); [0., -5.15699] Alternatively, you can try to get different single roots from fsolve by suppying different initial points (which may happen to converge to the distinct roots). This may involve trial and error. Eg, > eqn := x^4 + 5*x^3 + 4*x = sin(x): > fsolve(eqn,x=10.0); 0. > fsolve(eqn,x=-10.0); -5.156989371 Cheers, Dave Linder Team Lead, Mathematical Software, Maplesoft, Inc.