@Dragonsoul02 This complicated process seems sensitive to the maxstep done during the final dsolve. I'v adjusted that and got results in which O2r does not become negative (which I presume is physically impossible in the system that this attempts to model).

dsparint4.mw

I also tried to adjust some relative tolerances, along the following "rule". If A calls B (possibly many times) to compute a numerical approximation then the accuracy of each B result should generally be at least as good as the accuracy for which A is striving. Ie. you cannot make a silk purse from a sow's ear. Hence, I made the numeric interagtion step's `epsilon` accuracy tolerance be tighter than the `relerr` of final dsolve. And I made the `relerr` of the innermost dsolve be tighter than the numeric integration. Hopefully, this makes sense.

The attached worksheet takes longer than before. It now takes 360 sec to get to t=48 on my MS-Windows i7 machine, while my earlier inaccurate version took only 60 sec. The curves are also nice and smooth now, when plotted in Maple 15, giving more credence. And the results no longer disagree quantitatively, between Maple 15 and 16. The Maple 16 plot is a bit more jagged, but along the same paths. This revision seems a fair tradeoff, or speed for accuracy. (Incidentally, it only takes 280 sec on a 64bit Linux i5. Maybe dsolve numeric's engine could be produced with a better compiler.)

The whole scheme, involving parameters, seems to have pitfalls. That is: make the wrong adjustment and it takes forever to calculate, or set some tolerance poorly and the result is very inaccurate. And then there are the weird things, such as trying to redo any of it (except the plots) without a restart. I suppose that you had considered trying to roll the entire process into a larger system (according to calculus) with the hope that dsolve/numeric could resolve any accuracy requirements entirely on its own. Also, I have not experimented with other dsolve/numeric solvers for the final outermost stage.

@Markiyan Hirnyk I indicated in my answer that I didn't expect using the dot product to be relatively efficient. I had hoped that, by qualifying it right there in my answer, attentive readers would be able to anticipate the consequential effect on relative timings involving many repetitions.

I wasn't really joking, no. I was trying to make a suggestion that was simple to use in the case that not many similar repetitons were to be done.

Perhaps we can find something else interesting to take from this. Here's a fun example, albeit involving floating-point data (which the original example did not),

> A:=<1e15,1,-1e15>:                                                           
> add(x, x in A);
                                      0.

> A . <1,1,1>;
                                      1.

> A:=<1e17,1,-1e17>:
> add(x, x in A);
                                      0.

> A . <1,1,1>;
                                      0.

The point is not that the dot product is more careful in general.

@Markiyan Hirnyk I indicated in my answer that I didn't expect using the dot product to be relatively efficient. I had hoped that, by qualifying it right there in my answer, attentive readers would be able to anticipate the consequential effect on relative timings involving many repetitions.

I wasn't really joking, no. I was trying to make a suggestion that was simple to use in the case that not many similar repetitons were to be done.

Perhaps we can find something else interesting to take from this. Here's a fun example, albeit involving floating-point data (which the original example did not),

> A:=<1e15,1,-1e15>:                                                           
> add(x, x in A);
                                      0.

> A . <1,1,1>;
                                      1.

> A:=<1e17,1,-1e17>:
> add(x, x in A);
                                      0.

> A . <1,1,1>;
                                      0.

The point is not that the dot product is more careful in general.

Please upload the worksheet or paste the commands in plaintext 1D Maple notation inside a new Comment here, so that we can run it without having to type it all in ourselves and also so that we can reproduce your results. See the green up-arrow, to upload.

acer

@serena88 Put all the (38) names to which you have assigned all 38 equations into a list. Then build a new list of (38) new names to which you have applied the fnormal command. You can use the `map` command for that, or build it with `seq` (or even with a loop, if assigning to table entries).

Don't try and get the GUI to merely suppress the full display (elision) -- your program should be mathematically robust, so don't try and fake that with mere appearance. Make it robust, so that you truly know what is going on, and such actions are deliberate. Also, don't try and solve this by reducing Digits to some small value. Compute at necessary working precision (Digits) and  apply evalf[d] or fnormal command as necessary.

Trying shortcuts will undermine the correctness of your code.

@serena88 Put all the (38) names to which you have assigned all 38 equations into a list. Then build a new list of (38) new names to which you have applied the fnormal command. You can use the `map` command for that, or build it with `seq` (or even with a loop, if assigning to table entries).

Don't try and get the GUI to merely suppress the full display (elision) -- your program should be mathematically robust, so don't try and fake that with mere appearance. Make it robust, so that you truly know what is going on, and such actions are deliberate. Also, don't try and solve this by reducing Digits to some small value. Compute at necessary working precision (Digits) and  apply evalf[d] or fnormal command as necessary.

Trying shortcuts will undermine the correctness of your code.

There's quite a bit of interesting new functionality for managing colors in Maple 16's ColorTools package.

Here is a small example. (This is a chopped screenshot, since maplenet or whatever is used to inline worksheets into posts got it pretty wrong.) See the download link at the end.

colors.mw

acer

@mah00 I could be mistaken, but I believe that this is why DEtools:-phaseportrait did not show a direction field plot in your previous attempt as well,

> DEtools[autonomous]({DE[]},[x1,y1],t);

                             false

> DEtools[autonomous]({DE[]},[x2,y2],t);

                             false

See the Description sections of the help-pages for phaseportrait and DEplot. I don't see how it could be done with the fieldplot command either, for this system. Perhaps someone else could confirm or disprove.

@mah00 I could be mistaken, but I believe that this is why DEtools:-phaseportrait did not show a direction field plot in your previous attempt as well,

> DEtools[autonomous]({DE[]},[x1,y1],t);

                             false

> DEtools[autonomous]({DE[]},[x2,y2],t);

                             false

See the Description sections of the help-pages for phaseportrait and DEplot. I don't see how it could be done with the fieldplot command either, for this system. Perhaps someone else could confirm or disprove.

Hopefully dissection by StringTools would be minimal, and the bulk of the parsing be done by sscanf.

But the ability to automatically grab and process tabular data from webpages is useful.

A case in point: the software Fathom has some of this functionality, which I suspect was in part what allowed them to become [1] one of the few pieces of commercial software to get broad licensing in some Ontario education boards (which Maple has not had since Maple V, if I recall).

acer

@Markiyan Hirnyk Of course I read that comment carefully, just as I also read carefully the comment from which this post was branched.

I knew that a multi-start approach could be attained by simply giving options to DirectSearch. The author of the comment you cite didn't mention it specifically, but here is how DirectSearch offers such functionality at present,

DirectSearch:-DataFit(F
                      , [a=0..10, b=-10..10, c=0..100, d=0..7, e=0..4]
                      , X, Y, x
                      , optimizer=globalsearch
                      , evaluationlimit=30000
                      , number=10
                      , timelimit=60
                              );

With such a calling sequence, the DataFit command does 10 repeated starts, and does its best to adhere to a 60 second timelimit. One difference (which is important to me, and might be to others) is that the repeater wrapper allows one to receive asynchronous status messages (in the commandline or Classic interfaces, or in a Worksheet of the Standard GUI). I have not seen how to make DirectSearch produce such messages, on its own. If I call the DataFit command with a 24 hour timelimit, then I would certainly like to know how well it is progressing in the interim.

Also this wrapper has a certain amount of genericity about it. So it might be reused for other tasks with somewhat similar behaviour. Improvements and comments are welcome. I posted this because it might help someone else not have to reinvent the wheel.

The GlobalOptimization package exports a useful command, GetLastSolution. I believe that it can be used to retrieve the best value even when the computation is interrupted, and not just timed out. That kind of functionality is another possible improvement to this wrapper, as I mentioned. I'd be happy to be shown how, but as yet I haven't seen how it can be done at present using DirectSearch (unless one makes the extra effort to modify the objective procedure to do its own retainment bookkeeping -- which also might make it unevalhf'able and possibly slower).

@sreid I don't understand what you mean about Y's 9th value.

As the code stands, it looks like the Fit command is going to receive a Vector X of length 8 and a Vector Y of length 9, and that (in itself) will generate a runtime error.

@sreid I don't understand what you mean about Y's 9th value.

As the code stands, it looks like the Fit command is going to receive a Vector X of length 8 and a Vector Y of length 9, and that (in itself) will generate a runtime error.

@Dragonsoul02 The problem seems to lie with the IC of a(0)=0.

How do you interpret the first system, with that setting?

Specifying a(0) just a small amount above 0.0 seems to do better.

@Dragonsoul02 The problem seems to lie with the IC of a(0)=0.

How do you interpret the first system, with that setting?

Specifying a(0) just a small amount above 0.0 seems to do better.