@Markiyan Hirnyk Yes, I thought that was obvious.

I changed f2 from f1+2 to be f1+1, so that there was overlap. I think that the overlap illustrates better that the colors match for any given shared z-value, since with overlap more z-values (than just the singleton z=1) are shared.

And, of course, maxz and minz must get changed accordingly, if they are to be force fed for an example. I gave the appropriate maxz and minz for my example, with the different f2=f1+1.

This also relates to having a more general scheme (mine given at top being non-bug-free, I'm sure) which can extract the maximal and minimal z-values automatically.

@Markiyan Hirnyk Yes, I thought that was obvious.

I changed f2 from f1+2 to be f1+1, so that there was overlap. I think that the overlap illustrates better that the colors match for any given shared z-value, since with overlap more z-values (than just the singleton z=1) are shared.

And, of course, maxz and minz must get changed accordingly, if they are to be force fed for an example. I gave the appropriate maxz and minz for my example, with the different f2=f1+1.

This also relates to having a more general scheme (mine given at top being non-bug-free, I'm sure) which can extract the maximal and minimal z-values automatically.

@ThU I tried to show a more general mechanism, where one does not know in advance what the max and min values -- global over both f1 and f2 combined -- will be. Hence I dug it out of the initial plots. If one knows those in advance then the coding can be simpler.

And it can also be done without all the `op` and data structure manipulation. And it can look a little simpler with expressions instead of operators (...I think). Note that I didn't take any special care for efficiency before, either.

Download colorfun2b.mw

@ThU I tried to show a more general mechanism, where one does not know in advance what the max and min values -- global over both f1 and f2 combined -- will be. Hence I dug it out of the initial plots. If one knows those in advance then the coding can be simpler.

And it can also be done without all the `op` and data structure manipulation. And it can look a little simpler with expressions instead of operators (...I think). Note that I didn't take any special care for efficiency before, either.

Download colorfun2b.mw

I would say it even more strongly: it is a much worse idea to try and integrate and differentiate from an interpolated set of discrete data values that it is to instead work directly with the differential system.

So, if one has an ode system in Maple then do not first extract discrete values of the solution and then interpolate, and then integrate/differentiate/root-find/etc. It is generally a terrible idea to do so, from a numerical standpoint.

For integraton and differentiation it is likely a better idea in general to augment the ode system, and one should be able to find several posts about that on this site. For multiple root-finding of some expression in terms of the solution it is generally better to make the extra effort and use dsolve,events.

Suppose that you want to integrate the solution to some ode. Three possible ways are: 1) generate discrete data, interpolate, and integrate that interpolating result, 2) obtain a procedure from dsolve/numeric and then use evalf/Int on that, and 3) augment the ode with a new variable and a new equation (which sets that new variable equal to the derivative of what you want integrated) and call dsolve/numeric on the augmented ode.

Of these ways, 1) is by far the worst, numerically, in general.

I believe that 3) is generally better than 2), numerically, because the dsolve/numeric engine knows best how to do its own error analysis and step-size control dynamically to attain any requested tolerance. Whereas passing a piecewise interpolating procedure (as returned by dsolve/numeric) on to some numeric integrator introduces an unnecessary break in the informational flow. The evalf/Int integrator will be generally restricted in its accuracy by the fixed quality of the returned dsolve/numeric procedure.

Differentiation near the end-points of the original region of interest will be especially difficult to do effectively using an interpolating scheme from a precomputed set of data from the numerically solved ode.

acer

I would say it even more strongly: it is a much worse idea to try and integrate and differentiate from an interpolated set of discrete data values that it is to instead work directly with the differential system.

So, if one has an ode system in Maple then do not first extract discrete values of the solution and then interpolate, and then integrate/differentiate/root-find/etc. It is generally a terrible idea to do so, from a numerical standpoint.

For integraton and differentiation it is likely a better idea in general to augment the ode system, and one should be able to find several posts about that on this site. For multiple root-finding of some expression in terms of the solution it is generally better to make the extra effort and use dsolve,events.

Suppose that you want to integrate the solution to some ode. Three possible ways are: 1) generate discrete data, interpolate, and integrate that interpolating result, 2) obtain a procedure from dsolve/numeric and then use evalf/Int on that, and 3) augment the ode with a new variable and a new equation (which sets that new variable equal to the derivative of what you want integrated) and call dsolve/numeric on the augmented ode.

Of these ways, 1) is by far the worst, numerically, in general.

I believe that 3) is generally better than 2), numerically, because the dsolve/numeric engine knows best how to do its own error analysis and step-size control dynamically to attain any requested tolerance. Whereas passing a piecewise interpolating procedure (as returned by dsolve/numeric) on to some numeric integrator introduces an unnecessary break in the informational flow. The evalf/Int integrator will be generally restricted in its accuracy by the fixed quality of the returned dsolve/numeric procedure.

Differentiation near the end-points of the original region of interest will be especially difficult to do effectively using an interpolating scheme from a precomputed set of data from the numerically solved ode.

acer

@maple_matt_2 The subexpression does not appear explicitly in EQN. You would have had to copy the term and the bracketed term seperately (or done something similar) as the blue output of EQN has a term lying between those in the product subexpression.

But, sure, entering an explicit multiplication symbol may be better practice than trying to remember whether you had instead added a space between paste-ins.

This problem seems to come up quite often. Some people configure to use 1D Maple notation for input, because of the risk here.

@maple_matt_2 The subexpression does not appear explicitly in EQN. You would have had to copy the term and the bracketed term seperately (or done something similar) as the blue output of EQN has a term lying between those in the product subexpression.

But, sure, entering an explicit multiplication symbol may be better practice than trying to remember whether you had instead added a space between paste-ins.

This problem seems to come up quite often. Some people configure to use 1D Maple notation for input, because of the risk here.

@Christopher2222 Rebuilding the data file is not difficult.

I ran these commands, at the end of the Document (and then deleted those commands). I changed the data file name from "test.dat" to the more Windows-friendly "testdata.txt".

stuff:=DocumentTools:-GetProperty('plotter_',value):
writedata(cat(kernelopts(homedir),"/testdata.txt"),
          convert(op([1,3],[plottools:-getdata(stuff)]),listlist),
          float);

Since the above creates the data file "testdata.txt" in one's home directory/folder, I figure that would also be an OK place to put the "filenames.txt" file which is the applications master record of any data files it is supposed to handle. Therefore I added a line to the Document's hidden (code) document block to set the working directory to be cat(kernelopts(homedir),"/test.dat") so that it could find these two text files.

Here are the edited files. I removed the plot and output from the Document, so that one can see it changed as it works for the first time. The first two should be placed in whatever Maple reports as the output from running the command kernelopts(homedir).

filenames.txt

testdata.txt

DataAnalysis_edit.mw

Do you mean that you want the data in the plot that is (saved in) the PlotComponent? That component's name is 'plotter_'.

Open that worksheet, but with autoexecute turned off, and decline to execute automatically, when prompted. Then do this,

stuff:=DocumentTools:-GetProperty('plotter_',value);

In recent Maple you can use the plottools:-getdata command to extract the data (as rtables). But even in older versions you could now pick apart `stuff` using the op command.

plottools:-getdata(stuff);

I'm guessing that you want the Matrix in the ensuing  "points" substructure.

acer

@lpearce The integral succeeds for me using 64bit Maple 14.00 on both ubuntu 10.04 and 11.04.

But the integral failed for me, returning unevaluated, on 64bit ubuntu 12.04 with 64bit versions 14.00 and 14.01 of Maple. The problem now appears similar to this and this.

Note that ubuntu 12.04 came out some years after Maple 14 (2010), and is not on the list of supported platforms for that version.

@lpearce The integral succeeds for me using 64bit Maple 14.00 on both ubuntu 10.04 and 11.04.

But the integral failed for me, returning unevaluated, on 64bit ubuntu 12.04 with 64bit versions 14.00 and 14.01 of Maple. The problem now appears similar to this and this.

Note that ubuntu 12.04 came out some years after Maple 14 (2010), and is not on the list of supported platforms for that version.

@lpearce I also had success for that command with 64bit Maple 14.00 on Linux, when running in the commandline (tty) interface (started with the -s option to suppress default reading of initialization files).

It's hard to guess just exactly what the original cause might have been, for you.

@lpearce I also had success for that command with 64bit Maple 14.00 on Linux, when running in the commandline (tty) interface (started with the -s option to suppress default reading of initialization files).

It's hard to guess just exactly what the original cause might have been, for you.

Hmm. Now I am wondering what was wrong with this code in the original thread, and which also works in Maple 13, 12, and 11...

> proc () local t; t := proc () debugopts('callstack')[9] end proc; printf("%s;\n",eval(t)()) end proc();

proc () local t; t := proc () debugopts('callstack')[9] end proc; printf("%s;\n",eval(t)()) end proc();

That didn't rely upon first calling interface(), and doesn't call `print`. The calls to `printf` could be replaced by calls to `iolib` (and some printing mechanism must be used, because that is the task).