@PatrickT All three of those have the same URL.

@Samir Khan I had started looking at the manipulation behaviour if the data were set up as ISOSURFACE() instead of POINTS(). At smaller numPoints, at least, it seems responsive, although it takes longer to render than to produce. At numPoints=200 the rendering by the GUI seems to "go away forever". The lighting model doesn't seem to get used, as well, and that is unfortunate.

I haven't yet looked at MESH() for this.

@Samir Khan Ok, I've got some changes to the code already. (But I won't be able to finish until at least next week at the earliest, due to work deadlines.)

For numPoints=100, I got the memory allocation down from about 950MB to around 11MB, depending on the method. On an Intel i7 930 @2.8GHz (quad core) the time to produce the plot3d data structure is reduced from 11sec to about 1.4sec using a combination of Threads and evalhf, and about 0.8sec using the Compiler serially.

Using the revised code in Maple 15.01 on 64bit Windows 7 it was also easy to compute numPoints=200 in about 7sec, and numPoints=400 in about 65sec with a few hundred MB allocation.

Also of interest is that this evalhf approach took almost exactly four times as long when run serially compared with its Threaded version on that quad-core. Sure, we know that this computation should be embarassingly parallelizable, but achieving linear speed-up w.r.t the number of cores (with Maple Threads) is more usually another story altogether.

Samir, with your permission I'd like to embed the code into an Application worksheet which demonstrates the various timings by using radio boxes to allow an optimization choice of none/option-hfloat/evalhf/Compiled combined with an acceleration choice of serial/parallel. Of course, the parameters would also be adjustable.

The outstanding irritation is the time it takes the GUI to finish rendering such pointplots. They're not so large that the GUI always freezes merely by clicking on them. But they do cause the GUI to use much more memory, just to plot the structure.

Is there a better way to represent these fractal objects other than point-plots? Apart from being very slow to render they are difficult to see properly when numPoints gets high. I think that that's because the point-plot symbols visually merge together, and so the object does not look crisp. Nor does glossiness and the lightmodel affect a collection of many points symbols, like they do for a patchnogrid surface. What would be nice would be an implicit surface, ideally looking more like this. If any Maple expert has an opinion or suggestion for this visualization aspect it'd be welcome.

@goli I was not originally convinced that simplex[convexhull] was the best way to approach your goal.

The problem here is that some portions (which you hope to connect as if they lay on the nice convex curve segment) of your latest set of data points are only "close to" being convex.

We can see that the very first stage fails to do what was expected of it.

restart:

ch1 := [[0.5e-2, -.57], [0.1e-1, -.56], [0.25e-1, -.57], [0.35e-1, -.555], [0.8e-1, -.485],
 [0.9e-1, -.42], [.115, -.43], [.125, -.36], [.155, -.365], [.16, -.3], [.17, -.34],
 [.175, -.275], [.195, -.24], [.23, -.24], [.23, -.18], [.245, -.215], [.25, -.145],
 [.275, -.1], [.28, -.155], [.3, -.12], [.31, -0.35e-1], [.315, -0.25e-1], [.32, -0.85e-1],
 [.345, -0.4e-1], [.355, 0.55e-1], [.36, 0.65e-1], [.375, 0.15e-1], [.38, .11], [.39, .135],
 [.405, .175], [.41, .19], [.415, .205], [.425, .11], [.425, .24], [.425, .425], [.425, .43],
 [.425, .435], [.425, .44], [.43, .12], [.43, .265], [.43, .405], [.43, .41], [.43, .44],
 [.43, .445], [.435, .295], [.435, .38], [.435, .385], [.435, .445], [.44, .445], [.445, .445],
 [.45, .445], [.465, .195], [.465, .44], [.48, .43], [.485, .245], [.485, .425], [.49, .42],
 [.5, .29], [.5, .405], [.505, .31], [.505, .395], [.51, .345], [.51, .35], [.51, .355],
 [.51, .36], [.51, .365], [.51, .37]]:

ch11 := simplex[convexhull](ch1,output=[hull]):

ch1b:={op(ch1)} minus {op(ch11)}:

plots:-display( plot(ch11,style=point,symbol=solidbox,symbolsize=10,color=cyan),
                plot(ch11,color=cyan),
                plot(ch1b,style=point,symbol=solidbox,symbolsize=10)
               );

You should be able to see the problem points in the above plot. The problem is that the `convexhull` command does not accept a tolerance option in order to denote how far off a point canbe while still being acceptable. That's unfortunate.

Did you round the data for those points? If you rounded, and if you are lucky, then there may be more success with the unrounded data. For example the point [.17, -.34] might originally have been closer to [.17, -.3401] or so.

If retaining more decimal digits in the data doesn't cure this main issue then it still may be possible to write a more careful piece of (involved) code. It might fit a curve to the computed hull segment, and then find out which points are "close enough". And then adjust the set that was the computed hull. And so on.

Sorry, I don't have spare time to write that.

@goli I was not originally convinced that simplex[convexhull] was the best way to approach your goal.

The problem here is that some portions (which you hope to connect as if they lay on the nice convex curve segment) of your latest set of data points are only "close to" being convex.

We can see that the very first stage fails to do what was expected of it.

restart:

ch1 := [[0.5e-2, -.57], [0.1e-1, -.56], [0.25e-1, -.57], [0.35e-1, -.555], [0.8e-1, -.485],
 [0.9e-1, -.42], [.115, -.43], [.125, -.36], [.155, -.365], [.16, -.3], [.17, -.34],
 [.175, -.275], [.195, -.24], [.23, -.24], [.23, -.18], [.245, -.215], [.25, -.145],
 [.275, -.1], [.28, -.155], [.3, -.12], [.31, -0.35e-1], [.315, -0.25e-1], [.32, -0.85e-1],
 [.345, -0.4e-1], [.355, 0.55e-1], [.36, 0.65e-1], [.375, 0.15e-1], [.38, .11], [.39, .135],
 [.405, .175], [.41, .19], [.415, .205], [.425, .11], [.425, .24], [.425, .425], [.425, .43],
 [.425, .435], [.425, .44], [.43, .12], [.43, .265], [.43, .405], [.43, .41], [.43, .44],
 [.43, .445], [.435, .295], [.435, .38], [.435, .385], [.435, .445], [.44, .445], [.445, .445],
 [.45, .445], [.465, .195], [.465, .44], [.48, .43], [.485, .245], [.485, .425], [.49, .42],
 [.5, .29], [.5, .405], [.505, .31], [.505, .395], [.51, .345], [.51, .35], [.51, .355],
 [.51, .36], [.51, .365], [.51, .37]]:

ch11 := simplex[convexhull](ch1,output=[hull]):

ch1b:={op(ch1)} minus {op(ch11)}:

plots:-display( plot(ch11,style=point,symbol=solidbox,symbolsize=10,color=cyan),
                plot(ch11,color=cyan),
                plot(ch1b,style=point,symbol=solidbox,symbolsize=10)
               );

You should be able to see the problem points in the above plot. The problem is that the `convexhull` command does not accept a tolerance option in order to denote how far off a point canbe while still being acceptable. That's unfortunate.

Did you round the data for those points? If you rounded, and if you are lucky, then there may be more success with the unrounded data. For example the point [.17, -.34] might originally have been closer to [.17, -.3401] or so.

If retaining more decimal digits in the data doesn't cure this main issue then it still may be possible to write a more careful piece of (involved) code. It might fit a curve to the computed hull segment, and then find out which points are "close enough". And then adjust the set that was the computed hull. And so on.

Sorry, I don't have spare time to write that.

@tfr@nanophysics.dk I think that you have misunderstood. The first task is to decode the base64 and the dotm encodings of the 2D Math represented as Typesetting calls. The two encoding steps, as the first steps above, would have to be done if you want to get at the code in some way. And they do work. But they decode to an internal representation of 2D Math (which is a non-plaintext Maple language) marked up in Typesetting code.

Yes, of course it does not work to print the Typesetting form (of 2D Math) in a 1D environment. I only included that `print` call to demonstrate that the initial decoding steps had in fact worked to obtain a necessary intermediate form.

And then I subsequently added a Comment, illustrating how the 2D Math Typesetting representation might further be parsed and even finally evaluated/interpreted/executed as 1D Maple Notation code. And that worked too. But perhaps you had not yet read and digested it, before you made a conclusion about the first steps' purpose and success.

@tfr@nanophysics.dk I think that you have misunderstood. The first task is to decode the base64 and the dotm encodings of the 2D Math represented as Typesetting calls. The two encoding steps, as the first steps above, would have to be done if you want to get at the code in some way. And they do work. But they decode to an internal representation of 2D Math (which is a non-plaintext Maple language) marked up in Typesetting code.

Yes, of course it does not work to print the Typesetting form (of 2D Math) in a 1D environment. I only included that `print` call to demonstrate that the initial decoding steps had in fact worked to obtain a necessary intermediate form.

And then I subsequently added a Comment, illustrating how the 2D Math Typesetting representation might further be parsed and even finally evaluated/interpreted/executed as 1D Maple Notation code. And that worked too. But perhaps you had not yet read and digested it, before you made a conclusion about the first steps' purpose and success.

Your solution is pretty much the same as mine: try to handle the remaining points also with convexhull, and then try to join the pieces.

In general this may get tough. The posted example is next to trivial, and doesn't do justice to the potential difficulty. Someone will have a collection of points to be joined as a collection of many pieces, with inflections.

But I am wondering about where these points came from. Isn't the submitter also asking questions about DEs? if these come from numerically solving them, or simulating, then it might be that DEplot or odeplot can handle the problem directly (and so avoid all this effort at figuring out the spacecurve discretized as an ordered sequence of points.)

acer

Your solution is pretty much the same as mine: try to handle the remaining points also with convexhull, and then try to join the pieces.

In general this may get tough. The posted example is next to trivial, and doesn't do justice to the potential difficulty. Someone will have a collection of points to be joined as a collection of many pieces, with inflections.

But I am wondering about where these points came from. Isn't the submitter also asking questions about DEs? if these come from numerically solving them, or simulating, then it might be that DEplot or odeplot can handle the problem directly (and so avoid all this effort at figuring out the spacecurve discretized as an ordered sequence of points.)

acer

A few more ideas, for manipulating this result. (This is crude. You'd likely want it much more bulletproof and sophisticated. And it'd likely end up much different, if done carefully and properly.)

Continuing from the above...

> H:=Typesetting:-Parse(op(fromdotm)):

> HH:=remove(type,
>        StringTools:-Split(convert(op(-1,eval(H,1)),string),"1;"),
>        identical(" ",""));

                     ["A := 4", " B := 7"]

> seq(eval(parse(t)), t in HH):

> A, B;
                              4, 7

I'm not sure that I understand what part you plan for python in this. If you were to implement the entire scripting process using commandline Maple itself then you might more easily utilize (or get more ideas from) the exports of the `Worksheet`, `XMLTools`, and `Typesetting` packages.

[Also, some curiosities of scripting with commandline Maple.]

acer

A few more ideas, for manipulating this result. (This is crude. You'd likely want it much more bulletproof and sophisticated. And it'd likely end up much different, if done carefully and properly.)

Continuing from the above...

> H:=Typesetting:-Parse(op(fromdotm)):

> HH:=remove(type,
>        StringTools:-Split(convert(op(-1,eval(H,1)),string),"1;"),
>        identical(" ",""));

                     ["A := 4", " B := 7"]

> seq(eval(parse(t)), t in HH):

> A, B;
                              4, 7

I'm not sure that I understand what part you plan for python in this. If you were to implement the entire scripting process using commandline Maple itself then you might more easily utilize (or get more ideas from) the exports of the `Worksheet`, `XMLTools`, and `Typesetting` packages.

[Also, some curiosities of scripting with commandline Maple.]

acer

Right. Good job. For a few major releases now, non-evalhf'able commands can be executed within an evalhf'd procedure if they are wrapped in an `eval` call.

The (faster) evalhf callback from the openmaple API may be usable, then, with this trick. But the evaluation of the particular piece inside that extra `eval` is not actually interpreted under evalhf. The extra `eval` is behaving like a temporary escape from evalhf back to Maple's regular interpreter.

Exceptions to this behaviour include module member calls, like A:-B(blah), for which evalhf will still complain. One way to get around that is to instead call eval(H(blah)) where H is another procedure which itself calls A:-B.

acer

Right. Good job. For a few major releases now, non-evalhf'able commands can be executed within an evalhf'd procedure if they are wrapped in an `eval` call.

The (faster) evalhf callback from the openmaple API may be usable, then, with this trick. But the evaluation of the particular piece inside that extra `eval` is not actually interpreted under evalhf. The extra `eval` is behaving like a temporary escape from evalhf back to Maple's regular interpreter.

Exceptions to this behaviour include module member calls, like A:-B(blah), for which evalhf will still complain. One way to get around that is to instead call eval(H(blah)) where H is another procedure which itself calls A:-B.

acer

@icegood As far a I know, the `LerchPhi` command is not evalhf'able.

@icegood As far a I know, the `LerchPhi` command is not evalhf'able.