792 Reputation

11 Badges

9 years, 230 days

MaplePrimes Activity

These are replies submitted by sand15


Thank you Kitonum.

I'm often puzzled with the differences of behavior between  -> and unapply ... I guess I have to read more carefully the dedicated helps pages ...


Thanks acer
Loading 2015.2 here is not easily due to the very strict safety policy 

Nevertheless I will test this tomorrow with (some) version 2016.
Maybe I will join you later on from home, where I use 2015.2 on a imac.

Thanks again


Here it is

@Daniel Skoog 

Thanks Daniel,

I have just gave some info to acer.

About point 1 : this is a very interesting way to customize the DataSummary procedure
Concerning  your point 2 : right, a screenshot is a roundabout way to answer the question.

Thanks also for your last line, I appreciate that


Thank you acer.

I had aleady tried the plotsetup(jpeg, ...) command but I had got an error saying the embeded summary was not of plot type (did not tried textplot : I'm going to see righr now).
What do I mean by "save this table" : you are right, this is not clear. I mean "ideally" save the appearance of the table as an image ... just like some image capture tool could do.
Of course I could use fprintf to save these informations in a text file in a "smart" form, but I found that the appearance of
DataSummarize(...summarize=embed) was realy very smart.



It looks like our replies have crossed


I found myself the solution :-)
I just  declared  use plots  within the procedure and it  works correctly now.

(I thought that loading the package plots in the worksheet itself would be sufficient)

Sorry for the inconvenience



This works well but your answer made me realize that  I oversimplified my problem.
If it's not too much to ask, could you answer this one please ?

 f := proc(DrawThis)
     plotsetup(jpeg, plotoutput=SomeJpegFile);
end proc;

MyPlot := plot(x, x=0..1)
f(MyPlot);   # That's fine, thank you,

MyPlot := display(plot(x, x=0..1), plot(x^2, x=0..1))
f(MyPlot);   # No file is created

Even this simplified procedure
 f := proc(DrawThis)
end proc;

returns what I would have obtained by writting
MyPlot := display(plot(x, x=0..1), plot(x^2, x=0..1)) ;

Could you help me please ?

Thanks a lot for your fruitful help.
I tested tou .mw file and it works beond my expectations.



I am going to implement these two solutions and look what happens on my machine.

Thanks again



It works perfectly well


Thanks for the suggestion.

To make it more concrete ...

The unknown is a function r(x) which represents tjhe radius of a revolution object at abscissa. r(x) verifies a nonlinear first order ODE and I'm interested in the radius of curvarure of "solution shap" in some range of x. Assessing this radius by divided differences is not accurate, hence the idea to work with a piecewise solution.


Thank you for the information.

I had already used the work-around you refet to but the result is less nice.


Thanks again


I will have a look at this package.
Thanks for this alternative solution.


You wrote “We haven't been told the precise nature of the expressions that may be present…”

The  ODE system I am concerned with describes  the motion of N masses inside a closed box submitted to an outer acceleration. Within this box they are connectors that link each mass to another one or to the box. A connector between masses i  and j delivers a force on these two masses which depends of the displacements (x) and velocities (v) of the masses i and j (think to some generalization of a spring or a linear damper).
This force can be “simple” (an ideal spring) or more complex and highly nonlinear. A common situation concerns forces that come from experimental measurements: in this case the connector is pointwise defined and a continuous representation of it is obtained by piecewise reconstruction (often piecewise linear).
Then some expressions can be piecewise functions.

For each mass these  two ODEs are written (the upper arrow represents all the x or v variables)

diff(x[i](t), t) = v[i](t),   
F[i](t, (t),  (t))*diff(v[n](t), t) =         

 where the summation is extended to all masses j connected to mass i.

Maybe this will give you some ideas about the general problem.

Now a last point:  I use a Maple code written a few years ago and this code is “frozen” in the sense that it has been approved for simulating very critical phenomena. Modifying this code for it returns the “indets” of the system before the ODE system is constructed is technically simple. But it is incredibly complicated in terms of red tape.  One output of the code is the ODE system itself, so the idea to identify the “indets” from this output in order to prevent any modification (even light) of the code.

In any case I want to thank you for all the work you have been doing.


First 17 18 19 20 21 22 23 Page 19 of 25