pagan

5142 Reputation

23 Badges

16 years, 318 days

 

 

"A map that tried to pin down a sheep trail was just credible,

 but it was an optimistic map that tried to fix a the path made by the wind,

 or a path made across the grass by the shadow of flying birds."

                                                                 - _A Walk through H_, Peter Greenaway

 

MaplePrimes Activity


These are replies submitted by pagan

Doug's answer is great.

If modified like Doug suggests, and kept as a procedure, would `friccion` need to be passed to dsolve(numeric(...)) in the 'known'=list option?

Even if the poster could successfully use `piecewise` for this particular example, sometimes this kind of (unevaluated-returning) procedure is the right approach for this problem. It's unsettling that it's not one of the approaches/fixes described on the relevant Error Message Guide page. There are scenarios where 'operator form", or "uneval" right-single-quotes, is not going to work.

Doug's answer is great.

If modified like Doug suggests, and kept as a procedure, would `friccion` need to be passed to dsolve(numeric(...)) in the 'known'=list option?

Even if the poster could successfully use `piecewise` for this particular example, sometimes this kind of (unevaluated-returning) procedure is the right approach for this problem. It's unsettling that it's not one of the approaches/fixes described on the relevant Error Message Guide page. There are scenarios where 'operator form", or "uneval" right-single-quotes, is not going to work.

See this Question, from yesterday.

But if you've already solved it for the first derivative, then it is trivial. Just raise the d and dx to ^2, but only after inserting it as 2D Math using whatever you'd normally do for the first derivative.

@Britzel You've mentioned two approaches: animate, and a Plot Component (via Explore). Let's discuss the animate method first.

Here are some usage stats for the Maple kernel and whichever graphical user interface (GUI) is running, Standard or Classic. I know, you're running on a Mac and Classic isn't available. It's still worth mentioning. It's important to note that the GUI's memory resources are not accounted for by kernelopts(bytesalloc) which is the kernel memory allocation. And the status bar of the GUI seems to report a value most akin to the kernel memory allocation. Now, you can use utilities of your OS to get the GUI's memory use. There are also differences to be had between Document + 2D Math input and Worksheet + 1D Maple input, in the Standard GUI.

Here's what I see in 32bit Maple 15 for MS-Windows, as far as memory use goes when I run your uploaded code three times, split by `restart`, including creating and playing the animation at default frames. I completely close each, between runs. I start each run with .mw or .mws with all output removed in a previous save. Then I save each sheet with the animation, and measure the effect of that action.

             Standard(Document+2D)     Standard(Worksheet+1D)       Classic

kernel             197 MB                     131 MB                 131 MB

  GUI              351 MB                     351 MB                 240 MB

GUI+save           530 MB                     500 MB                 270 MB

Total allocation for the Maple session which computed and saved the sheet would be the first row added to the third row above. So I can believe that if you double the number of frames, from the default, that the combined memory allocation by both GUI and kernel could be over 1 GB.

Now, about Explore. All that command is doing for your DEplot example is fire up a new Document and embed in it a Plot Component, some sliders, and code to glue them together. But some of the code is in a colapsed block, with some globals used, etc, so it's not easy to cut and paste the whole ensemble back to your orginal worksheet. But that's ok because you can quite easily do it by hand as well, right in your main sheet. (And because it's not based on a general purpose template, like Explore, your solution can have neat and tidy code.) I don't have time for that right now, but someone else might also easily show it for the very simple 2-parameter ode example used with Explore in a response above. I'm going to think a bit about your other question: could individual DEplot outputs (plot structures, really) be precomputed and saved in a table, with sliders instead hooked up just to call plots:-display on them?

There is something else I'm not sure about. There was a memory use bug a while back (Maple 12-14, I think, and 15?) in which dsolve/numeric would store solutions internally (remember-table or cache or whatever). So if you were doing say Optimization with dsolve/numeric calls in the objective function then you really better be using the new parameter functionality and not just individual dsolve/numeric calls on reinstantiations of the ode system by new parameter values. Doing the latter would allocate huge memory, not reclaimable until restart. Now, you can whip up a smart wrapper around dsolve/numeric and the new parameter functionality, and have that wrapper be the argument to plots:-odeplot. But DEplot doesn't work like that. It expects the original system and not a proc ouput from dsolve/numeric. So I don't know how to get around this issue (if still relevant) when using DEplot. Hmm. Maybe there is a remember table to be sniffed out. But this may be a red herring in that it might not be the main culprit from the kernel side of things.

It's a shame that the plot structure coming out of DEplot is not optimal for storage and replacement. There is no arrow primitive, and there's a ton of CURVES subobjects Arrays. And the main curve is listlist of HFloat which is not nearly as lean as hardware datatype Array. Now, 25 * 25 = 625 such plot structures for animation data, at 25 frames in two parameter directions. It looks like your initial, single DEplot is 4<->8 MB plot structure. So storing 25 is not too hard and contributes to the kernel allocation figure. But 25*25=625 isa lot to store, for a pair of parameter sliders. And who knows that the GUI is storing in all that allocated memory. So I suspect that a precomputed DEplot approach, for manual replay in a Component say, is too costly.

Animations have long been too memory hungry, even in Classic days. Fixing it might require changing the whole mechanism. Who really needs a plot structure, for just an animation which (apart from playing) you often won't interact with? An image could be leanest. Is it worth its being so slow and greedy, just so that you can change the axes and style postcomputation?

@Britzel You've mentioned two approaches: animate, and a Plot Component (via Explore). Let's discuss the animate method first.

Here are some usage stats for the Maple kernel and whichever graphical user interface (GUI) is running, Standard or Classic. I know, you're running on a Mac and Classic isn't available. It's still worth mentioning. It's important to note that the GUI's memory resources are not accounted for by kernelopts(bytesalloc) which is the kernel memory allocation. And the status bar of the GUI seems to report a value most akin to the kernel memory allocation. Now, you can use utilities of your OS to get the GUI's memory use. There are also differences to be had between Document + 2D Math input and Worksheet + 1D Maple input, in the Standard GUI.

Here's what I see in 32bit Maple 15 for MS-Windows, as far as memory use goes when I run your uploaded code three times, split by `restart`, including creating and playing the animation at default frames. I completely close each, between runs. I start each run with .mw or .mws with all output removed in a previous save. Then I save each sheet with the animation, and measure the effect of that action.

             Standard(Document+2D)     Standard(Worksheet+1D)       Classic

kernel             197 MB                     131 MB                 131 MB

  GUI              351 MB                     351 MB                 240 MB

GUI+save           530 MB                     500 MB                 270 MB

Total allocation for the Maple session which computed and saved the sheet would be the first row added to the third row above. So I can believe that if you double the number of frames, from the default, that the combined memory allocation by both GUI and kernel could be over 1 GB.

Now, about Explore. All that command is doing for your DEplot example is fire up a new Document and embed in it a Plot Component, some sliders, and code to glue them together. But some of the code is in a colapsed block, with some globals used, etc, so it's not easy to cut and paste the whole ensemble back to your orginal worksheet. But that's ok because you can quite easily do it by hand as well, right in your main sheet. (And because it's not based on a general purpose template, like Explore, your solution can have neat and tidy code.) I don't have time for that right now, but someone else might also easily show it for the very simple 2-parameter ode example used with Explore in a response above. I'm going to think a bit about your other question: could individual DEplot outputs (plot structures, really) be precomputed and saved in a table, with sliders instead hooked up just to call plots:-display on them?

There is something else I'm not sure about. There was a memory use bug a while back (Maple 12-14, I think, and 15?) in which dsolve/numeric would store solutions internally (remember-table or cache or whatever). So if you were doing say Optimization with dsolve/numeric calls in the objective function then you really better be using the new parameter functionality and not just individual dsolve/numeric calls on reinstantiations of the ode system by new parameter values. Doing the latter would allocate huge memory, not reclaimable until restart. Now, you can whip up a smart wrapper around dsolve/numeric and the new parameter functionality, and have that wrapper be the argument to plots:-odeplot. But DEplot doesn't work like that. It expects the original system and not a proc ouput from dsolve/numeric. So I don't know how to get around this issue (if still relevant) when using DEplot. Hmm. Maybe there is a remember table to be sniffed out. But this may be a red herring in that it might not be the main culprit from the kernel side of things.

It's a shame that the plot structure coming out of DEplot is not optimal for storage and replacement. There is no arrow primitive, and there's a ton of CURVES subobjects Arrays. And the main curve is listlist of HFloat which is not nearly as lean as hardware datatype Array. Now, 25 * 25 = 625 such plot structures for animation data, at 25 frames in two parameter directions. It looks like your initial, single DEplot is 4<->8 MB plot structure. So storing 25 is not too hard and contributes to the kernel allocation figure. But 25*25=625 isa lot to store, for a pair of parameter sliders. And who knows that the GUI is storing in all that allocated memory. So I suspect that a precomputed DEplot approach, for manual replay in a Component say, is too costly.

Animations have long been too memory hungry, even in Classic days. Fixing it might require changing the whole mechanism. Who really needs a plot structure, for just an animation which (apart from playing) you often won't interact with? An image could be leanest. Is it worth its being so slow and greedy, just so that you can change the axes and style postcomputation?

@john2032 I don't know how you entered your original. Did you use the palettes (left-panel of the Standard Graphical User Interface, by default)?

If you entered the summation as 2D Math input, then at some point you would have had to enter the upper and lower bounds for the summation index, as well as the expression to be summed. I'm suggesting that you supply some slightly different quantities. I'm suggesting changing the `i` to `(2*i-1)` inside the expression to be summed, and changing to upper bound on the summation index from `n` to `(n+1)/2`.

The difference between the following two (1D notation) inputs should indicate how to change what you insert into the 2D Math ("graphical", I think you are calling it) input.

sum( cos(i*omega*t)/i^2, i=1..7 );

sum( cos((2*i-1)*omega*t)/(2*i-1)^2, i=1..(7+1)/2 );

The change to the upper value of the index is less important, as it is you who decides how many terms you'll want. The key is changing the `i` in the expression.

Is your problem that you already have the expression formed, with just `i` in it? You can change it with the `subs` command.

expr := cos(i*omega*t)/i^2;

newexpr := subs( i=(2*i-1), expr );

sum( newexpr, i=1..(7+1)/2 );

@john2032 I don't know how you entered your original. Did you use the palettes (left-panel of the Standard Graphical User Interface, by default)?

If you entered the summation as 2D Math input, then at some point you would have had to enter the upper and lower bounds for the summation index, as well as the expression to be summed. I'm suggesting that you supply some slightly different quantities. I'm suggesting changing the `i` to `(2*i-1)` inside the expression to be summed, and changing to upper bound on the summation index from `n` to `(n+1)/2`.

The difference between the following two (1D notation) inputs should indicate how to change what you insert into the 2D Math ("graphical", I think you are calling it) input.

sum( cos(i*omega*t)/i^2, i=1..7 );

sum( cos((2*i-1)*omega*t)/(2*i-1)^2, i=1..(7+1)/2 );

The change to the upper value of the index is less important, as it is you who decides how many terms you'll want. The key is changing the `i` in the expression.

Is your problem that you already have the expression formed, with just `i` in it? You can change it with the `subs` command.

expr := cos(i*omega*t)/i^2;

newexpr := subs( i=(2*i-1), expr );

sum( newexpr, i=1..(7+1)/2 );

Is the presence of the units conversion inside the conditional test of the while-loop deliberate, and intended somehow as part of the heavy load?

StringTools:-ParseTime and StringTools:-FormatTime (or Finance:-FormatDate) can be used for this task.

It helps to have a function which easily tells how many days are between two dates (for this specific task that Christopher mentions). Finance:-DayCount can be used for that. But, for what it's worth

> Finance:-DayCount("Feb-1-2000","Mar-1-2000");
                               29

> Finance:-DayCount("Feb-1-1900","Mar-1-1900");

Error, (in Finance:-DayCount) year 1900 out of bound. It must be in [1901,2099]

@Britzel The window in the new worksheet, in which you see the plots, after calling Explore, is a Plot Component. If you right-click on it, and then choose Component->Component Properties from the menu popup, you'll be able to see a new dialogue box which has editable entry fields for the width and height of that Component. (You can also change them with a command, but only after it is created and not from the Explore call.)

I forgot to mention, if you change either of the two range end-points for any of the Explore parameters to a float (eg, 2.0 instead of 2, or 0.0 instead of 0) then that slider will take on many more values between the major ticks and it won't take only integer values. It makes for a smoother look and feel, depending on your computer of course.

I'm not sure why saving your animation causes problems. Could you upload your code here? How many frames in the created animation? What is kernelopts(bytesalloc) afterwards? You say that you are using DEplot. Does that mean that you're calling DEplot with a new ode system, for each parameter value change? That sounds like a lot of individual dsolve/numeric calls.

It's a shame, perhaps, that so many DEtools routines accept only the ode system and not the result of dsolve/numeric in the way that plots:-odeplot does. Since the odeplot routine accepts a dsolve/numeric output procedure, you can feed it a hand-written procedure or appliable module that does this: On the first time through it calls dsolve/numeric with parameters option, then calls the returned solution procedure sets parameters, then returns the solution procedure after assigning it to a global or module local. On subsequent times through it just sets the parameter values using that same global of module local procedure itself, and then returns it. In this way, odeplot can be used and only form an whole solution procedure once. This probably saves all sorts of repeated overhead in dsolve/numeric, just like when similar techniques are used for Optimization, etc. But as far as I can tell the other DEtools routines only accept the ode system, and not the returned procedure. And it sound like you don't want odeplot, because you want to do "flows".

@Britzel The window in the new worksheet, in which you see the plots, after calling Explore, is a Plot Component. If you right-click on it, and then choose Component->Component Properties from the menu popup, you'll be able to see a new dialogue box which has editable entry fields for the width and height of that Component. (You can also change them with a command, but only after it is created and not from the Explore call.)

I forgot to mention, if you change either of the two range end-points for any of the Explore parameters to a float (eg, 2.0 instead of 2, or 0.0 instead of 0) then that slider will take on many more values between the major ticks and it won't take only integer values. It makes for a smoother look and feel, depending on your computer of course.

I'm not sure why saving your animation causes problems. Could you upload your code here? How many frames in the created animation? What is kernelopts(bytesalloc) afterwards? You say that you are using DEplot. Does that mean that you're calling DEplot with a new ode system, for each parameter value change? That sounds like a lot of individual dsolve/numeric calls.

It's a shame, perhaps, that so many DEtools routines accept only the ode system and not the result of dsolve/numeric in the way that plots:-odeplot does. Since the odeplot routine accepts a dsolve/numeric output procedure, you can feed it a hand-written procedure or appliable module that does this: On the first time through it calls dsolve/numeric with parameters option, then calls the returned solution procedure sets parameters, then returns the solution procedure after assigning it to a global or module local. On subsequent times through it just sets the parameter values using that same global of module local procedure itself, and then returns it. In this way, odeplot can be used and only form an whole solution procedure once. This probably saves all sorts of repeated overhead in dsolve/numeric, just like when similar techniques are used for Optimization, etc. But as far as I can tell the other DEtools routines only accept the ode system, and not the returned procedure. And it sound like you don't want odeplot, because you want to do "flows".

It shouldn't assign to the global name datelisting since that is the return value.

Avoid side-effects like that as a rule, when practical. In this case, using a global is completely unnecessary.

It's interesting that you did it. Having obtained the explicit result you then plotted it. But generating a plot, or numerically solving or optimizing, etc, all do not require an explicit solution. The question asked above remains unanswered: do you have a purpose which in fact requires the explicit form? How well does your method scale to large problems?

It's interesting that you did it. Having obtained the explicit result you then plotted it. But generating a plot, or numerically solving or optimizing, etc, all do not require an explicit solution. The question asked above remains unanswered: do you have a purpose which in fact requires the explicit form? How well does your method scale to large problems?

@PatrickT 

Patrick, that other post you cite had 4 upvotes already, when Preben added his (amazing) comment. So 4 of 5 upvotes were certainly for the original post. I agree with you that voting up comments would be nice as a token of agreement. But your cited example didn't actually support the point.

It would be unhelpful, though, if up votes on comments affected their ordering within a thread. Successive comments often refer to their predecessors and (much like a conversation) the order matters! Votes are a mechanism for ranking Answers. Their original purpose is wasn't glory. Nobody complains of up votes without accompanying explanations, and it's inconsistent to expect down votes be any different. A down vote should be about shame as much as an upvote should be about pride and hubris, ie. not at all.

First 24 25 26 27 28 29 30 Last Page 26 of 81