Multiple plots: oddities (bugs?), missing features in Xmaxima and wxMaxima

----- Original Message -----

> From: Mark H Weaver <mhw at netris.org>
> 
> Virgil L <virgilinux at yahoo.com> writes:
>>  It is also relevant that -- as far as I know -- ?the
>>  explicit/implicit?declaration is used EVERY time, even in the simplest
>>  of all plots, whereas other specifications are only used in certain
>>  cases.?
> 
> This is not true.? explicit() and implicit() are just two of many
> different kinds of graphic objects understood by draw2d.? Others
> include: bars(), ellipse(), errors(), image(), label(), parametric(),
> points(), polar(), polygon(), quadrilateral(), rectangle(), region(),
> triangle(), and vector().? More may be added in the future.


Sorry, what I meant is that this specification (plot type, that is, explicit/implicit/parametric/whatever) is needed in every use (choose one of them), even in the simplest cases. This is different from other specifications that are only used in specific kinds of plots. The point is that "optimising" this aspect makes more sense than if it only affected very particular cases.

I appreciate the rest of your post, as it seems to provide some technical explanations about how things work internally in draw2d. I cannot say I follow all of it, but that isn't surprising to me, since I am not familiar with lisp (the underlying programming system), and I tend to do most of my programming in relatively higher-level "environments" such as or similar to matlab/octave/scilab.

Anyhow,

> So you see, an equation at the beginning of draw2d's parameter list
> already has a well-defined meaning.? In order to implement what you
> suggest, we'd have to overload the meaning of an equation at the
> beginning of the parameter list, which would create the potential for
> symbol name conflicts between draw2d's options and user's equations.


It is possible that what you have in mind is more sophisticated (and potentially more useful) than what I have in mind.
What I suggest are purely _syntactic_ identities of the sort:

?explicit(f(x),x,x1,x2) ==?[f(x),[x,x1,x2]]
?implicit(f(x,y)=0,x,x1,x2,y,y1,y2) ==?[f(x,y)=0,[x,x1,x2],[y,y1,y2]]

?parametric(f(t),g(t),t,t1,t2)) ==?[[f(t),g(t)],[t,t1,t2]]


As you can probably tell, the left has today's draw2d syntax, whereas the right is (similar to) plot2d's.
>?Unfortunately,?we cannot make that change now without breaking lots of existing code.
>?
> Fortunately, as Mario has already pointed out, it is trivial to create

> convenience functions for the common cases you want.


Given my limited understanding of these issues, it would seem that the above "identities" could be implemented at the _syntactic_ level inside draw2d without utilising "overloading" or any sophisticated scheme, and without breaking or making any significant change to the underlying code.

The idea is that the draw2d "interpreter" would in principle look for the the presence of any of the constructs on left-hand side of the identities. If any is found the function would work exactly as it does today. If none is found, instead of returning an error, it would look for the presence of one of the constructs on the right-side. If one is found, it would make the "translation" to the equivalent one in the left, and after that it would work EXACTLY as it does today.

Notice that after a construct on the right is translated to its equivalent on the left, draw2d's underlying algorithm would work??EXACTLY as it does today, that is, the underlying algorithm (the one that actually does the plotting) would "see" ?explicit(f(x),x,x1,x2) whether the user has typed it exactly like that, or whether the user wrote?[f(x),[x,x1,x2]]?and it was "translated" to explicit(f(x),x,x1,x2) .

Other plot types could be left as they are today, or similar identities could be developed for the others.?


Sorry, if the above doesn't make sense.?

Best,

Virgil