That example also worked out using `simplify` instead of `combine`.

But what about this one?

f1:=x->piecewise(x>0,cos(x),1);

f2:=x->piecewise(x>0,sin(x),1);

acer

The number of views of a blog posting used to be shown here, beside the entry.

After a year or so of mapleprimes (the long "beta"?) that functionality was removed. I once posted about that, and the response (by Will? I can't find it now) was that someone would look into it.

acer

`add` is faster than `sum` for this sort of thing. It was about 2.5 times faster to compute p(2000) using `add` rather than `sum`, for example.

Writing a truly recursive procedure `s`, with option remember, is also faster than the above `sum` code (but not as fast as with `add`). But it could help, if you intend on computing some sorts of very long sets of increasing values with it.

s := proc(n)
local k;
option remember;
    if n = 1 or n = 2 then return 1
    else for k from 2 to n do
            s(k) := 2*add(s(i)*s(k - i), i = 1 .. k - 2) + s(k - 1)
        end do
    end if;
    s(n)
end proc:

So, once s(2000) is computed then s(1000) is computed near instantaneously, as it only requires a remember-table lookup.

I didn't bother considering whether there is any closed form of any of this.

acer

`add` is faster than `sum` for this sort of thing. It was about 2.5 times faster to compute p(2000) using `add` rather than `sum`, for example.

Writing a truly recursive procedure `s`, with option remember, is also faster than the above `sum` code (but not as fast as with `add`). But it could help, if you intend on computing some sorts of very long sets of increasing values with it.

s := proc(n)
local k;
option remember;
    if n = 1 or n = 2 then return 1
    else for k from 2 to n do
            s(k) := 2*add(s(i)*s(k - i), i = 1 .. k - 2) + s(k - 1)
        end do
    end if;
    s(n)
end proc:

So, once s(2000) is computed then s(1000) is computed near instantaneously, as it only requires a remember-table lookup.

I didn't bother considering whether there is any closed form of any of this.

acer

Do you mean this one, attributed to Ramanujan? (Using natural logarithm, so adjusted by factor of ln(10.)).

> ff := n*ln(n) - n + ln(n*(1+4*n*(1+2*n)))/6 + ln(Pi)/2;

        ff := n ln(n) - n + 1/6 ln(n (1 + 4 n (1 + 2 n))) + 1/2 ln(Pi)

> evalf[30](evalf[5000](eval(ff,n=3000)/ln(10.)));
                        9130.61798107450627025514189604

> evalf[30](ln(evalf[5000](3000!))/ln(10.));
                        9130.61798107450628141828801479

> evalf[30](evalf[5000](eval(ff,n=2^32)/ln(10.)));
                                                        11
                     0.395079669763461126642613649132 10

> trunc(%);
                                  39507966976

So, the above is indicating 39507966976 decimal digits in (2^32)!.

acer

Do you mean this one, attributed to Ramanujan? (Using natural logarithm, so adjusted by factor of ln(10.)).

> ff := n*ln(n) - n + ln(n*(1+4*n*(1+2*n)))/6 + ln(Pi)/2;

        ff := n ln(n) - n + 1/6 ln(n (1 + 4 n (1 + 2 n))) + 1/2 ln(Pi)

> evalf[30](evalf[5000](eval(ff,n=3000)/ln(10.)));
                        9130.61798107450627025514189604

> evalf[30](ln(evalf[5000](3000!))/ln(10.));
                        9130.61798107450628141828801479

> evalf[30](evalf[5000](eval(ff,n=2^32)/ln(10.)));
                                                        11
                     0.395079669763461126642613649132 10

> trunc(%);
                                  39507966976

So, the above is indicating 39507966976 decimal digits in (2^32)!.

acer

I see. The problem is that this is a number so large that attempting to compute it in the most obvious way -- by raising Maple's working precision -- may well fail. In such situations, there may be transformations which allow one to ascertain some quantitative properties of the number.

Are you looking for the leading digits of the floating-point representation of this number?

1/ln(2)*ln(GAMMA(4294967297));

If so, then how many digits would you need to find?

Or would knowing the exponent, in base 10, suffice?

(That question can be modified analogously, for numbers large enough, to "how many digits of the exponent would you need, or would the exponent of the exponent suffice? And so on.)

acer

I see. The problem is that this is a number so large that attempting to compute it in the most obvious way -- by raising Maple's working precision -- may well fail. In such situations, there may be transformations which allow one to ascertain some quantitative properties of the number.

Are you looking for the leading digits of the floating-point representation of this number?

1/ln(2)*ln(GAMMA(4294967297));

If so, then how many digits would you need to find?

Or would knowing the exponent, in base 10, suffice?

(That question can be modified analogously, for numbers large enough, to "how many digits of the exponent would you need, or would the exponent of the exponent suffice? And so on.)

acer

I think that the idea is to run just one of those. The first (export) is for Bourne shell (or its relatives like bash and zsh) while the second (setenv) is for C shell (or tcsh).

If the first worked for you, then you shouldn't need to run the second.

acer

I believe that the -z option (to Maple) disables Compiler:-Compile as well as wrapper-generating external-calling. Without -z, both of those mechanisms could be made to execute arbitary shell commands (with the authority of the user running the Maple session).

The trick was to embed the commands in a string prepended to (say) the linker command or linker options. To do that with the Compiler, it was necessary to call it once to initialize its internal settings, and then to change the external linker command using undocumented internals of that Compiler module, and then to call Compile once again. To do it with wrapper-generating external-calling was easy, as the means of setting compiler/linker flags by using a Maple record is fully documented. I submitted working examples (software change requests) to illustrate both of these situations. In Maple 11, if the -z switch is omitted when starting up Maple, then the Standard GUI's disable-system-commands option was inadequate to prevent this breach.

Using wrapperless external-calling, it was straightforward to call system functions (eg. from libc.so on Linux).

For anyone concerned with security In Maple, I would suggest looking at the Security page (tab) in the Options menu in the Standard GUI. The level of granularity for security control is much improved in Maple 12. I was not able to get any of the breaches mentioned above to function, with the relevant security settings enabled from this menu. The disable-system-calls button disabled the Compiler (good). External libraries like libc.so, outside of Maple's own binaries, could be disallowed for wrapperless external-calling (good). And warnings/queries could be toggled for autoexecution of .mla archives or worksheets or worksheet execution groups.

acer

I believe that the -z option (to Maple) disables Compiler:-Compile as well as wrapper-generating external-calling. Without -z, both of those mechanisms could be made to execute arbitary shell commands (with the authority of the user running the Maple session).

The trick was to embed the commands in a string prepended to (say) the linker command or linker options. To do that with the Compiler, it was necessary to call it once to initialize its internal settings, and then to change the external linker command using undocumented internals of that Compiler module, and then to call Compile once again. To do it with wrapper-generating external-calling was easy, as the means of setting compiler/linker flags by using a Maple record is fully documented. I submitted working examples (software change requests) to illustrate both of these situations. In Maple 11, if the -z switch is omitted when starting up Maple, then the Standard GUI's disable-system-commands option was inadequate to prevent this breach.

Using wrapperless external-calling, it was straightforward to call system functions (eg. from libc.so on Linux).

For anyone concerned with security In Maple, I would suggest looking at the Security page (tab) in the Options menu in the Standard GUI. The level of granularity for security control is much improved in Maple 12. I was not able to get any of the breaches mentioned above to function, with the relevant security settings enabled from this menu. The disable-system-calls button disabled the Compiler (good). External libraries like libc.so, outside of Maple's own binaries, could be disallowed for wrapperless external-calling (good). And warnings/queries could be toggled for autoexecution of .mla archives or worksheets or worksheet execution groups.

acer

I don't see any reason to believe that this is related to kernelopts(datalimit), the parent shell's limits, or similar.

It might in fact be coded right into the (external) shared library called by RootFinding:-Isolate, and be a separate management mechanism.

The OP might raise limits in the parent shell by using (say) ulimit, and then in Maple itself with kernelopts(), and see whether that gets rid of the problem altogether.

acer

This looks like an internal error message that is not supposed to surface. You might consider submitting a report about it.

The author of the code would probably like to see an example that produced the error reliably (if you have such).

I could not find such an error statement in the RootFinding:-Isolate command at the Maple library level. But it does exist in the compiled shared library libfgbuni.so. And the ?Isolate help-page does not mention it.

acer

The Statistics:-NonlinearFit help-page says that it uses a least squares approach.  It seemed straightforward to adapt Joe's (2nd) approach evaluating the DE (at a point t) to one which did a sum of squares for the data points in T and Z.

B := proc(a,b,c)
global T,Z;
local G,i;
for i from 1 to 11 do
    G[i]:=zcompute(T[i],a,b,c);
end do;
add( (G[i]-Z[i])^2, i=1..11 );
end proc:

Once one has this objective function, in can be used with the GlobalSolve routine.

As mentioned before, GlobalSolve has a a lot of options that can be adjusted to vary how it searches.

infolevel[GlobalOptimization]:=10:
Digits := trunc(evalhf(Digits)):

GlobalOptimization:-GlobalSolve(B, 0..0.2,0..0.2,0..0.5, 
   optimalitytolerance=1.0e-6, method=singlestart,
   noimprovementlimit=400, timelimit=10000,
   evaluationlimit=500000);

Quite quickly it found the triple 4.973755e-02, 1.612033e-03, 1.462690e-01 for p1, p2, and f. I forget for which values of the solver options it found something good fastest. That triple gives an ever so slightly smaller (better) residual (total error, in least-squares) when fed into the objective function B than does the result from NonlinearFit or from that other 3rd party package.

Depending on the specific problem, you might wish to set various options and have GlobalSolve search for as long as you have patience.

You asked about the 'parameters' option for dsolve/numeric. The dsolve(...,numeric) routine doesn't itself provide the numeric solution to DEs. It returns something which can subsequently be run to provide numeric values. It sets up a solver to do that, and returns a procedure (or list of such) that when run will themselves return the numeric values. But what if one has a generic DE of some form, and knows in advance that it will have to be solved numerically for various different values of some parameters (coefficients, etc) wihin it? One doesn't want to have to call all the heavy expensive machinery each time a parameter is adjusted, just to produce the solving-procedures which appear the same (except for the change in parameters). And indeed, your optimization problem seems to be a perfect example of why such efficient parametric numeric DE solving is necessary. How does it work? I don't know -- maybe it's just using Maple's lexical scoping functionality, and supplying the 'parameters' option informs dsolve/numeric that this will be OK at runtime. The option is briefly mention, but not fully described, on the ?dsolve[numeric,IVP] help-page.

acer

The Statistics:-NonlinearFit help-page says that it uses a least squares approach.  It seemed straightforward to adapt Joe's (2nd) approach evaluating the DE (at a point t) to one which did a sum of squares for the data points in T and Z.

B := proc(a,b,c)
global T,Z;
local G,i;
for i from 1 to 11 do
    G[i]:=zcompute(T[i],a,b,c);
end do;
add( (G[i]-Z[i])^2, i=1..11 );
end proc:

Once one has this objective function, in can be used with the GlobalSolve routine.

As mentioned before, GlobalSolve has a a lot of options that can be adjusted to vary how it searches.

infolevel[GlobalOptimization]:=10:
Digits := trunc(evalhf(Digits)):

GlobalOptimization:-GlobalSolve(B, 0..0.2,0..0.2,0..0.5, 
   optimalitytolerance=1.0e-6, method=singlestart,
   noimprovementlimit=400, timelimit=10000,
   evaluationlimit=500000);

Quite quickly it found the triple 4.973755e-02, 1.612033e-03, 1.462690e-01 for p1, p2, and f. I forget for which values of the solver options it found something good fastest. That triple gives an ever so slightly smaller (better) residual (total error, in least-squares) when fed into the objective function B than does the result from NonlinearFit or from that other 3rd party package.

Depending on the specific problem, you might wish to set various options and have GlobalSolve search for as long as you have patience.

You asked about the 'parameters' option for dsolve/numeric. The dsolve(...,numeric) routine doesn't itself provide the numeric solution to DEs. It returns something which can subsequently be run to provide numeric values. It sets up a solver to do that, and returns a procedure (or list of such) that when run will themselves return the numeric values. But what if one has a generic DE of some form, and knows in advance that it will have to be solved numerically for various different values of some parameters (coefficients, etc) wihin it? One doesn't want to have to call all the heavy expensive machinery each time a parameter is adjusted, just to produce the solving-procedures which appear the same (except for the change in parameters). And indeed, your optimization problem seems to be a perfect example of why such efficient parametric numeric DE solving is necessary. How does it work? I don't know -- maybe it's just using Maple's lexical scoping functionality, and supplying the 'parameters' option informs dsolve/numeric that this will be OK at runtime. The option is briefly mention, but not fully described, on the ?dsolve[numeric,IVP] help-page.

acer