It's disturbing how often instances of this problem get reported here. I count 4 or 5 times in the past couple of months. Which raises the question of how often it occurs and is not reported here.

I wonder how it occurs, whether the cause is preventable and, if not, why the GUI itself cannot accomplish a repair more reliably.

acer

It's disturbing how often instances of this problem get reported here. I count 4 or 5 times in the past couple of months. Which raises the question of how often it occurs and is not reported here.

I wonder how it occurs, whether the cause is preventable and, if not, why the GUI itself cannot accomplish a repair more reliably.

acer

@alex_01 In order for the debugger to be invoked when LPSolve gets called all one needs to do is,

stopat(Optimization:-LPSolve);

and then call Optimization:-LPSolve on some example.

@alex_01 In order for the debugger to be invoked when LPSolve gets called all one needs to do is,

stopat(Optimization:-LPSolve);

and then call Optimization:-LPSolve on some example.

@alex_01 You are very welcome, though you are giving me too much credit. All I did was run the first example of ?LPSolve under the debugger, and walked through until it came to the routine that did the conversion.

What you might find most interesting is that your R and ER appear "as is" inside `A` the Matrix of inequalities. You can also see this visually, if you set N=3 and print `A`. So it may illustrate the principal -- in Matrix form, there are just numeric coefficients, and no variables appearing explicitly by (symbolic) name.

@alex_01 You are very welcome, though you are giving me too much credit. All I did was run the first example of ?LPSolve under the debugger, and walked through until it came to the routine that did the conversion.

What you might find most interesting is that your R and ER appear "as is" inside `A` the Matrix of inequalities. You can also see this visually, if you set N=3 and print `A`. So it may illustrate the principal -- in Matrix form, there are just numeric coefficients, and no variables appearing explicitly by (symbolic) name.

If memory is a concern then in the non-inline case your code doesn't need to create all the A[i] up front, does it? Couldn't it form and export them one at a time, to limit the total allocation necessary at any given time?

Also, if you're just rotating, why not try this for efficiency,

  - copy orig plot's data to temp Array

  - rotate temp Array data, inplace

  - wash, rinse, repeat

see here for code to rotate temp Array inplace (maybe, forget if you have MESH or GRID).

acer

If memory is a concern then in the non-inline case your code doesn't need to create all the A[i] up front, does it? Couldn't it form and export them one at a time, to limit the total allocation necessary at any given time?

Also, if you're just rotating, why not try this for efficiency,

  - copy orig plot's data to temp Array

  - rotate temp Array data, inplace

  - wash, rinse, repeat

see here for code to rotate temp Array inplace (maybe, forget if you have MESH or GRID).

acer

@PatrickT There is an old Maple joke, that it would be much easier to get better numerics out of Maple if only they were to remove all the symbolics.

There is also another joke, which goes similarly but with the words symbolics and numerics exchanged.

@PatrickT There is an old Maple joke, that it would be much easier to get better numerics out of Maple if only they were to remove all the symbolics.

There is also another joke, which goes similarly but with the words symbolics and numerics exchanged.

I suggest that you do not use the MapletBuilder, if you can instead write the Maplet code by hand.

A reason is that the Builder can produce code which is more difficult to manually correct or enhance, especially as the project gets larger. But the Builder is not all-powerful, and at some point you may well face a problem that you cannot surmount with it. At that point you'd have to either start over from scratch, authoring by hand, or you'd have the more difficult task of untangling what the Builder had authored.

acer

@PatrickT If you overlay with a transparent image, then that is a foreground and not a background.

If a layer is overlaid on top (or, anywhere but at the very back) of the composite of several images, then it is not the background of the result (by defn). It's hard to see why a transparent foreground used in a final composite would earlier have been the background of either of the separate images. Why would anyone create something with a transparent background? Just so that they could superimpose on top of something else? That seems strained -- why not a transparent foreground on the original?

Anyway... Maple plots have neither convenient foreground nor background. Maybe we might keep it simple for now, and focus on the background.

I think that it would be useful if an area larger than what can get bounded by the axes were to be such a background. I'd rather have light text overlaid on top of a black background be consistent with light axes and tickmarks that are completely contained by the background. This is not possible to achieve now, with any of the techniques of plotting a "filled region" (unless the axes are faked, which can be too much work).

An image or background color for a Plot Component might suffice, as long as its access were fully programmatic.

The situation is more severe for 3D plots where, due to possible rotation, the background really must be painted before any part of the plot is. And it has to be wider as the plot's visible dimensions change with rotation.

@Christopher2222 Thanks for explaining about the missing answer. Using implicitplot sounds like a relatively costly way to fill the whole region, compared with a single polygon (one of the basic PLOT structure elements). Perhaps that was the reason for some of the down votes.

But in any case, something simpler that either of those two would be nice.

There is another kind of awkwardness situation with manually supplied filler. Suppose one builds a plot, P1, carefully placing the black background filler correctly in the sequence of plotted objects so that gets painted below all else. And it displays fine. Then the same again, for new plot P2. So a little extra effort was made in forming P1 and P2. And now one wishes to display them both together. But neither order for supplying P1 and P2 directly to plots:-display will work, because the black background of whichever is painted on top will completely obscure the entire other plot. So either piecemeal reconstruction, or removal of all but the lowest background layer, becomes necessary. I just mention it as another issue, along with having to rejig the foreground colors, etc. Ideally, the system would do all this for us.

@PatrickT Using the procedure BF that I posted above:

Without proper Array bounds (or shifts and offsets) that BF code currently only gets the bottom left quadrant of the wikipedia images for the Gauss map, since it cannot hande the negative values (the Array bounds are strctly positive, for one thing...). Also recall that the image is currently produced upside down, but can be flipped with one command.

# Gauss iterated map

m := BF(r+exp(-4.9*(x-1)^2),0,2,800,800,50000,-0.5):

ImageTools:-View(ImageTools:-Flip(m,'vertical'));

m := BF(r+exp(-6.3*(x-1)^2),0,2,800,800,50000,-0.5):

ImageTools:-View(ImageTools:-Flip(m,'vertical'));

As you likely already found, the Tent map is straightforward.

# Tent map

m := BF(r*min(x,1-x),1,2,800,800,50000,0.5):

ImageTools:-View(ImageTools:-Flip(m,'vertical'));

@carizard Try spelling it correctly, as VectorCalculus instead of VektorCalculus.