@J4James The first plot produced by the worksheet attached to this Comment looks like so, using the parameter values and IVP you suggested,

I made some adjustments/corrections to the code. (It runs ok for me in Maple 16.02)

magdeparam.mw

@J4James The first plot produced by the worksheet attached to this Comment looks like so, using the parameter values and IVP you suggested,

I made some adjustments/corrections to the code. (It runs ok for me in Maple 16.02)

magdeparam.mw

@J4James That shouldn't be a problem, and is likely just adjustments to accomodate multiple CURVE() & Matrices in the outer plot. Then it's bookkeeping, to get the corners of the magnification window.

I'm not sure when I can get  time, as there is fresh snow and tobogganing with the kids to do. Hopefully in an evening, if nobody else does it first.

@J4James That shouldn't be a problem, and is likely just adjustments to accomodate multiple CURVE() & Matrices in the outer plot. Then it's bookkeeping, to get the corners of the magnification window.

I'm not sure when I can get  time, as there is fresh snow and tobogganing with the kids to do. Hopefully in an evening, if nobody else does it first.

@J4James 

There are limits to the effectiveness of "zooming" (scaling), since the fineness and accuracy of the results from executing the procedures (like `X(t)` below) returned by dsolve/numeric are determined when dsolve is itself called.

Download magde.mw

@J4James 

There are limits to the effectiveness of "zooming" (scaling), since the fineness and accuracy of the results from executing the procedures (like `X(t)` below) returned by dsolve/numeric are determined when dsolve is itself called.

Download magde.mw

Maple 16.02 (64bit, on Windows 7),

restart:

GammaDist := int((lambda^k)*(z^(k-1))*(exp(-lambda*z))/(k-1)!,
                 z=0..t):

GammaDensity := diff(GammaDist, t):

simplify(combine(convert(GammaDensity,exp)));


                (k - 1)       k                 
               t        lambda  exp(-lambda t) k
               ---------------------------------
                         factorial(k)     
      
convert(simplify(convert(simplify(GammaDensity),exp)),factorial);

                 (k - 1)       k               
                t        lambda  exp(-lambda t)
                -------------------------------
                       factorial(k - 1)        

acer

Maple 16.02 (64bit, on Windows 7),

restart:

GammaDist := int((lambda^k)*(z^(k-1))*(exp(-lambda*z))/(k-1)!,
                 z=0..t):

GammaDensity := diff(GammaDist, t):

simplify(combine(convert(GammaDensity,exp)));


                (k - 1)       k                 
               t        lambda  exp(-lambda t) k
               ---------------------------------
                         factorial(k)     
      
convert(simplify(convert(simplify(GammaDensity),exp)),factorial);

                 (k - 1)       k               
                t        lambda  exp(-lambda t)
                -------------------------------
                       factorial(k - 1)        

acer

There are no routines in Maple for NetCDF per se, as far as I know.

FYI, a question was asked here about the system of formats HDF5 which is a subset of what NetCDF can support.

I suspect that plain wrapperless external calling from Maple would likely not suffice, and that (hand-written) wrappers would be needed. (...and then those would need to be precompiled, if distributed to others, etc).

To support these things comprehensively looks like a big job. Is it worth doing the simplest kind of examples first, and then trying to build up to multiple datatypes and containers, in steps? Or would that just satisfy almost nobody, so that lobbying for the Full Thing would be better?

acer

@Markiyan Hirnyk Or course. No such restriction was mentioned in the original Question, and without seeing his code we are in no position to judge it so (unless you can read minds, which previously you have indicated was not the case). I explicitly stated only that, "The following two examples are the same except for using `s` versus `s1`."

If `s1` appeared only in that one line, and even if what was inside that `evalf` call had no more usual global side-effects, then the statement could still affect memory ordering. For example, that could affect set element access in older versions of Maple, but we don't know which version he's using.

We'd likely need to see you code, or at least a small representative sample which reproduces the problem, in order to give best advice.

Are you using sets? There are scenarios in which is makes a difference that set element access is ordered (by name, lexicographically, in recent Maple versions). The following two examples are the same except for using `s` versus `s1`.

restart:
G := {s0, s1, s00}:
T := [t0=10^20, t1=1.0e-5, t00=-1.0e20]:
s0 := eval(t0,T): s00 := eval(t00,T):

s1 := evalf( eval(t1,T) ):

add( G[i], i=1..nops(G) );

                            0.000010

restart:
G := {s0, s, s00}:
T := [t0=10^20, t1=1.0e-5, t00=-1.0e20]:
s0 := eval(t0,T): s00 := eval(t00,T):

s := evalf( eval(t1,T) ):

add( G[i], i=1..nops(G) );

                               0.

acer

@Alejandro Jakubi I agree with your assessment of the functionality. Thanks. I was forgetting the (relatively new-ish) `parametric` option, in my comment's paragraph.

But, to address Markiyan's concerns, my comment contained a presumption rather than a claim. I interpret `solve(eqs,vars)` to be a request for solutions containing only the names in `vars` on the LHS. How else should it be interpreted as different from `solve(eqs)`? And if there are any equations (not trivially identical to zero) in `eqs` which contain none of the names in `vars` then they will not be satisfied by such a solution. The procedure SolveTools:-LinearSolvers:-PolynomialCleanup may be key to the processing here.

@Alejandro Jakubi I agree with your assessment of the functionality. Thanks. I was forgetting the (relatively new-ish) `parametric` option, in my comment's paragraph.

But, to address Markiyan's concerns, my comment contained a presumption rather than a claim. I interpret `solve(eqs,vars)` to be a request for solutions containing only the names in `vars` on the LHS. How else should it be interpreted as different from `solve(eqs)`? And if there are any equations (not trivially identical to zero) in `eqs` which contain none of the names in `vars` then they will not be satisfied by such a solution. The procedure SolveTools:-LinearSolvers:-PolynomialCleanup may be key to the processing here.

I believe that Preben's response is on the right track.

I'm not sure whether the solve help-pages make it clear enough (for systems of multivariate equations) just what is the definition of a solution according to the various possible calling sequences.

I suspect that a working definition of a "solution" to a call like,

    solve( eqs, vars );

is that evaluation at the returned result will satisfy all the equations. (It doesn't matter whether `eqs` are equations, or expressions which are taken to imply equations.)

Now, it may happen that there are other variables present in `eqs` which are not included in `vars`. The given calling sequence of the `solve` command appears to mean that any "solution" will only contain equations whose left hand sides are in `vars`. I didn't find this aspect described in any `solve` help-page, but then also I didn't find anything else like a tight set of definitions of a "solution" to a system of equations according to the various calling sequence possibilities. I will presume that this is an interpretation that agrees with `solve`'s design and behaviour for the remainder of this Comment.

So `solve({eq1,eq2},{d})` would return solutions containing only equations with `d` on the left hand side.

For the given example no single equation of the form `d=expr` can (by itself alone) satisfy both `eq1` and `eq2`. Or, more generally, it may be that no set consisting only of equations like var[i]=expr[i] for var[i] in `vars` would satisfy all equations in `eqs`.

In that case `solve` would return NULL, as no equation d=expr alone can satisfy both equations.

Consider the output from,

restart;

eq1:=s=a+b+c+d:
eq2:=s=2*(a+b)*(a+c)*(b+c):

eliminate({eq1,eq2},d);

      [                      /        2        2                    2
      [{d = s - a - b - c}, { -s + 2 a  b + 2 a  c + 4 a c b + 2 a c 
      [                      \                                       

                2        2          2\ ]
           + 2 b  a + 2 b  c + 2 b c  }]
                                     / ]

The first element of that output is of the form `d=expr`. Notice that `s` is not free in the (only) expression (implying an equation set to zero) in the set as the second entry of that output. This means that `solve({eq1,eq2},{d,s})` is a quite different request than is `solve({eq1,eq2},{d})`. Having the expression (in the set appearing as the second entry) in the above result from `eliminate` equal zero implies that `s=function_of_abc`. I see the second entry in the above result from `eliminate` as another way of encapsulating the notion that no single equation `d=expr` can alone satisfy both `eq1` and `eq2`, as there is a algebraic relationship amongst a,b,c, and s which does not involve d.

But if all this is correct interpretation then there is a useful bit of functionality missing from the `solve` command. It is the ability to force a non-trivial RHS in the equation `d=expr` in a result from calling `solve`. Let's suppose that you wish to avoid solutions containing `d=d`, if possible. If you simply invoke `solve(eqs)` and leave out the `vars` then there may be some choice of which variables appear in the solution trivially like `var[i]=var[i]` (as if they were parameters, say). One might want to specificy in a call to the `solve` command that `d=expr` appears with `expr` not identical to symbol `d`, and that any other variables could be inserted into the "solution" that would allow all original equations in `eqs` to be satisfied. If there were a choice as to what else to eliminate then `solve` might programmed choose. Eg. `s` might be chosen in the given example because doing so provides a simple explicit solution.

Why do I feel like this has been discussed before?

acer

I believe that Preben's response is on the right track.

I'm not sure whether the solve help-pages make it clear enough (for systems of multivariate equations) just what is the definition of a solution according to the various possible calling sequences.

I suspect that a working definition of a "solution" to a call like,

    solve( eqs, vars );

is that evaluation at the returned result will satisfy all the equations. (It doesn't matter whether `eqs` are equations, or expressions which are taken to imply equations.)

Now, it may happen that there are other variables present in `eqs` which are not included in `vars`. The given calling sequence of the `solve` command appears to mean that any "solution" will only contain equations whose left hand sides are in `vars`. I didn't find this aspect described in any `solve` help-page, but then also I didn't find anything else like a tight set of definitions of a "solution" to a system of equations according to the various calling sequence possibilities. I will presume that this is an interpretation that agrees with `solve`'s design and behaviour for the remainder of this Comment.

So `solve({eq1,eq2},{d})` would return solutions containing only equations with `d` on the left hand side.

For the given example no single equation of the form `d=expr` can (by itself alone) satisfy both `eq1` and `eq2`. Or, more generally, it may be that no set consisting only of equations like var[i]=expr[i] for var[i] in `vars` would satisfy all equations in `eqs`.

In that case `solve` would return NULL, as no equation d=expr alone can satisfy both equations.

Consider the output from,

restart;

eq1:=s=a+b+c+d:
eq2:=s=2*(a+b)*(a+c)*(b+c):

eliminate({eq1,eq2},d);

      [                      /        2        2                    2
      [{d = s - a - b - c}, { -s + 2 a  b + 2 a  c + 4 a c b + 2 a c 
      [                      \                                       

                2        2          2\ ]
           + 2 b  a + 2 b  c + 2 b c  }]
                                     / ]

The first element of that output is of the form `d=expr`. Notice that `s` is not free in the (only) expression (implying an equation set to zero) in the set as the second entry of that output. This means that `solve({eq1,eq2},{d,s})` is a quite different request than is `solve({eq1,eq2},{d})`. Having the expression (in the set appearing as the second entry) in the above result from `eliminate` equal zero implies that `s=function_of_abc`. I see the second entry in the above result from `eliminate` as another way of encapsulating the notion that no single equation `d=expr` can alone satisfy both `eq1` and `eq2`, as there is a algebraic relationship amongst a,b,c, and s which does not involve d.

But if all this is correct interpretation then there is a useful bit of functionality missing from the `solve` command. It is the ability to force a non-trivial RHS in the equation `d=expr` in a result from calling `solve`. Let's suppose that you wish to avoid solutions containing `d=d`, if possible. If you simply invoke `solve(eqs)` and leave out the `vars` then there may be some choice of which variables appear in the solution trivially like `var[i]=var[i]` (as if they were parameters, say). One might want to specificy in a call to the `solve` command that `d=expr` appears with `expr` not identical to symbol `d`, and that any other variables could be inserted into the "solution" that would allow all original equations in `eqs` to be satisfied. If there were a choice as to what else to eliminate then `solve` might programmed choose. Eg. `s` might be chosen in the given example because doing so provides a simple explicit solution.

Why do I feel like this has been discussed before?

acer