@Jeff Given your sorted x Array, and the values in the s Array, you can generate the piecewise programmatically as shown in the second example below.

The simple trick is to pass each of the pairs -- conditional & value -- as the operands of a list. This tricks `seq`, which would otherwise take each conditional & value pair as being separate arguments. Without the wrapping op([...]) then using `seq` this way would result in an invalid-input error as `seq` would misinterpret the s[i] as a second argument.

> Sold := piecewise(
>    x[0] <= t and t <= x[1], s[0],
>    x[1] <= t and t <= x[2], s[1],
>    x[2] <= t and t <= x[3], s[2]);

               /                    
      piecewise\6 <= t and t <= 45, 

                                    2               3  
        -103. + 27. t + 18. (t - 6.)  + 25. (t - 6.) , 

        45 <= t and t <= 93, 

                                      2                3  
        -4276. + 96. t + 52. (t - 45.)  + 90. (t - 45.) , 

        93 <= t and t <= 96, 

                                      2                3\
        -1481. + 17. t + 56. (t - 93.)  + 93. (t - 93.) /

> Snew := piecewise(seq(op([x[i] <= t and t <= x[i+1], s[i]]), i=0..2));

               /                    
      piecewise\6 <= t and t <= 45, 

                                    2               3  
        -103. + 27. t + 18. (t - 6.)  + 25. (t - 6.) , 

        45 <= t and t <= 93, 

                                      2                3  
        -4276. + 96. t + 52. (t - 45.)  + 90. (t - 45.) , 

        93 <= t and t <= 96, 

                                      2                3\
        -1481. + 17. t + 56. (t - 93.)  + 93. (t - 93.) /

@Jeff Given your sorted x Array, and the values in the s Array, you can generate the piecewise programmatically as shown in the second example below.

The simple trick is to pass each of the pairs -- conditional & value -- as the operands of a list. This tricks `seq`, which would otherwise take each conditional & value pair as being separate arguments. Without the wrapping op([...]) then using `seq` this way would result in an invalid-input error as `seq` would misinterpret the s[i] as a second argument.

> Sold := piecewise(
>    x[0] <= t and t <= x[1], s[0],
>    x[1] <= t and t <= x[2], s[1],
>    x[2] <= t and t <= x[3], s[2]);

               /                    
      piecewise\6 <= t and t <= 45, 

                                    2               3  
        -103. + 27. t + 18. (t - 6.)  + 25. (t - 6.) , 

        45 <= t and t <= 93, 

                                      2                3  
        -4276. + 96. t + 52. (t - 45.)  + 90. (t - 45.) , 

        93 <= t and t <= 96, 

                                      2                3\
        -1481. + 17. t + 56. (t - 93.)  + 93. (t - 93.) /

> Snew := piecewise(seq(op([x[i] <= t and t <= x[i+1], s[i]]), i=0..2));

               /                    
      piecewise\6 <= t and t <= 45, 

                                    2               3  
        -103. + 27. t + 18. (t - 6.)  + 25. (t - 6.) , 

        45 <= t and t <= 93, 

                                      2                3  
        -4276. + 96. t + 52. (t - 45.)  + 90. (t - 45.) , 

        93 <= t and t <= 96, 

                                      2                3\
        -1481. + 17. t + 56. (t - 93.)  + 93. (t - 93.) /

A recent note about the 100th anniversary of the Cholesky matrix factorization method appeared on NA Digest.

See also (Links section, at bottom) here.

@Christopher2222 Are there instances in which you can successfully switch to a pre-opened second sheet (for copy n' paste from the first sheet) after the first mserver crashes, but in which you cannot subsequently open a new sheet anyway? If so then there'd be no special virtue in opening the second sheet until/unless the first crashes, and it'd also be easier to figure out which mserver process to kill if you hadn't opened the second sheet in advance.

@Christopher2222 Are there instances in which you can successfully switch to a pre-opened second sheet (for copy n' paste from the first sheet) after the first mserver crashes, but in which you cannot subsequently open a new sheet anyway? If so then there'd be no special virtue in opening the second sheet until/unless the first crashes, and it'd also be easier to figure out which mserver process to kill if you hadn't opened the second sheet in advance.

That gets the nontrivial example from that Mma help page, too.

> int(piecewise(x^2+y^2<=1,1,0),x=-1..1,y=-1..1);
                               Pi

(It seems to get it wrong, if the integrand is first converted to Heaviside with defaults.)

But this goes away,

int(piecewise(x^2+y^2<=sqrt(2)/2,1,0),x=-1..1,y=-1..1);

although evalf/Int does better with epsilon=1e-4 and method=_MonteCarlo. Can it be done exactly, simply and correctly with such approaches?

That gets the nontrivial example from that Mma help page, too.

> int(piecewise(x^2+y^2<=1,1,0),x=-1..1,y=-1..1);
                               Pi

(It seems to get it wrong, if the integrand is first converted to Heaviside with defaults.)

But this goes away,

int(piecewise(x^2+y^2<=sqrt(2)/2,1,0),x=-1..1,y=-1..1);

although evalf/Int does better with epsilon=1e-4 and method=_MonteCarlo. Can it be done exactly, simply and correctly with such approaches?

@Alec Mihailovs It is fascinating that you are able to access the Maple Cloud, Alec. I am not surprised!

I'm curious as to whether you figured it out by examining packets primarily, or some mix of network traffic inspection alongside a published API (Google!?). I wonder whether your implementation is in Maple (Sockets package or external-calling), or in some other programming language.

It seems that Alec Mihailovs may have accomplished this. He wrote, "I wrote several functions accessing MapleCloud programmatically from any [Maple 14] interface...".

Since Alec is highly talented and appears honest, I have only reason to believe the claim.

I'm glad you got what you need.

It's generally inefficient to wrap A_ inside yet another procedure A if not necessary. (Function call cost can sometimes add up and be noticable.)

Also, using your wrapping `A` means that `evalhf` will also get called at each evaluation. That is more inefficient, as plot/fsolve/Optimization/evalf(Int) each already use their own mechanisms to ensure floating-point evaluation (the most simple of which being `evalhf`). So with the wrapped A_ you've got 3 function calls for each point, instead of 1.

As for numerical integration, what you say about the need to wrap procedures to allow the NAG quadrature methods to function might be true in some (other) example, but it's not true as a rule.

> restart:
> spikes:=sort([seq(RandomTools[Generate](distribution(Uniform(0,5))),i=1..300)]):
> Spikes:=add(rand()/1e12*exp(-(Z-spikes[i])^2/2/.001^2)/(1+Z)^(5/2),i=1..nops(spikes)):

> f := unapply(Spikes,Z):

> evalf(Int(f, 0..5, method=_d01akc));
                         0.04379364710

Basically, the whole "if not type(..,numeric) then 'procname'(args)" thing is just one of several ways to allow function calls to be passed to commands like in that set I mentioned. If you have a procedure of just one argument then you can simply do plot(f,a..b) and there is usually no need for other approaches to the issue like plot('f'(x),x=a..b) or plot(f(x),x=a..b) with `f` doing the 'procname' call on nonnumeric arguments. In the multivariate case with one parameter unfixed, your wrapped approach or plot('f'(Q,T,y),y=a..b) for fixed numeric Q,T can be very useful.

I'm glad you got what you need.

It's generally inefficient to wrap A_ inside yet another procedure A if not necessary. (Function call cost can sometimes add up and be noticable.)

Also, using your wrapping `A` means that `evalhf` will also get called at each evaluation. That is more inefficient, as plot/fsolve/Optimization/evalf(Int) each already use their own mechanisms to ensure floating-point evaluation (the most simple of which being `evalhf`). So with the wrapped A_ you've got 3 function calls for each point, instead of 1.

As for numerical integration, what you say about the need to wrap procedures to allow the NAG quadrature methods to function might be true in some (other) example, but it's not true as a rule.

> restart:
> spikes:=sort([seq(RandomTools[Generate](distribution(Uniform(0,5))),i=1..300)]):
> Spikes:=add(rand()/1e12*exp(-(Z-spikes[i])^2/2/.001^2)/(1+Z)^(5/2),i=1..nops(spikes)):

> f := unapply(Spikes,Z):

> evalf(Int(f, 0..5, method=_d01akc));
                         0.04379364710

Basically, the whole "if not type(..,numeric) then 'procname'(args)" thing is just one of several ways to allow function calls to be passed to commands like in that set I mentioned. If you have a procedure of just one argument then you can simply do plot(f,a..b) and there is usually no need for other approaches to the issue like plot('f'(x),x=a..b) or plot(f(x),x=a..b) with `f` doing the 'procname' call on nonnumeric arguments. In the multivariate case with one parameter unfixed, your wrapped approach or plot('f'(Q,T,y),y=a..b) for fixed numeric Q,T can be very useful.

I see. It wasn't clear until now that you meant Worksheets rather than Documents, when you wrote of the GUI. I'm sorry, I missed that it was ok on your 10.4.11 OSX.

I guess that you've already upgraded Maple to the point-release 11.02.

I notice that Maple 13.02 is described as being the first to "officially" support OSX 10.6.

I see. It wasn't clear until now that you meant Worksheets rather than Documents, when you wrote of the GUI. I'm sorry, I missed that it was ok on your 10.4.11 OSX.

I guess that you've already upgraded Maple to the point-release 11.02.

I notice that Maple 13.02 is described as being the first to "officially" support OSX 10.6.

@Alejandro Jakubi The Maple developers who post here appear to be mostly kernel and math developers, not GUI developers. And as Jacques has mentioned here a few times in the past: developers as a whole don't make such decisions. Product or group management make such decisions. Also, it's very resource consuming to port a flagship application's entire GUI to an completely different development platform. It's rarely the sort of thing you do unless you absolutely have to.

It took 5-6 years for the Standard to go from being unusable in Maple 9 to being pretty good in Maple 14. I would guess that the remaining performance issues of Standard on larger plot-filled worksheets could be improved, while retaining Java as the base, with some effort. But I hope that it doesn't take another 5-6 years.

@Alejandro Jakubi The Maple developers who post here appear to be mostly kernel and math developers, not GUI developers. And as Jacques has mentioned here a few times in the past: developers as a whole don't make such decisions. Product or group management make such decisions. Also, it's very resource consuming to port a flagship application's entire GUI to an completely different development platform. It's rarely the sort of thing you do unless you absolutely have to.

It took 5-6 years for the Standard to go from being unusable in Maple 9 to being pretty good in Maple 14. I would guess that the remaining performance issues of Standard on larger plot-filled worksheets could be improved, while retaining Java as the base, with some effort. But I hope that it doesn't take another 5-6 years.