There needs to be a graph object, with methods

[Slumberland]

The grapher has been defined as an image compositor.

Oops.

:)

Symptoms:

-- Render an animated .gif to have an animated graph.

-- show(A + B)     ('plus'?   That's a BLIT.  Also, the syntax is inconsistent.  It changes from "add the functions A and B" precisely where the graph object fails to have any meaningful mathematical input, and instead requires "the composition of A && B".  Complete change of context, at the wrong time.)

-- all the parameters which (should) belong to the grapher are instead duplicated in the various plot() methods.  They overlap, and there are then additional routines to sort out the overlap.  e.g. "show axes", "aspect ratio".

-- Where there are not routines to sort it out, the behavior is equally odd.  If the "xmin" and "xmax" values are different for two plot()  calls, only parts of the function show, when they are added to the same image.  All but one definition of display range is accidentally converted to a function evaluation range.

-- the solve method is not properly separated from the display method.  implicit_plot(), plot(), parametric_plot().  But the coordinate space is, in reality, completely independent of the method used to solve the equation.

This seems like a situation where Python could maybe benefit from your expertise.  Is it possible to talk to the Python developers about replacing some of the default methods and definitions over time, if they are incorrectly matched to the relationships they are designed to describe?  I can't see how it is possible to realize the desired improvements to Interact, with an image Blitter.   :-(

[Andrea Lazzarotto]

2012/7/1 Slumberland <rkh...@gmail.com>

-- all the parameters which (should) belong to the grapher are instead duplicated in the various plot() methods.  They overlap, and there are then additional routines to sort out the overlap.  e.g. "show axes", "aspect ratio".

-- Where there are not routines to sort it out, the behavior is equally odd.  If the "xmin" and "xmax" values are different for two plot()  calls, only parts of the function show, when they are added to the same image.  All but one definition of display range is accidentally converted to a function evaluation range.

I don't know if it can be considered to be related, but I noticed in some cases that when plotting a 3d implicit plot if I put the "mesh=True" in the plot it doesn't show up, but when inside the show method it does show up (in Jmol, not in Tachyon). This is confusing because it seems natural to define various properties of the plot inside the plot itself, as many other parameters work in both methods.

--
Andrea Lazzarotto - http://andrealazzarotto.com

[Slumberland]

On Sunday, July 1, 2012 2:47:16 AM UTC-7, Andrea Lazzarotto wrote:

I don't know if it can be considered to be related, but I noticed in some cases that when plotting a 3d implicit plot if I put the "mesh=True" in the plot it doesn't show up, but when inside the show method it does show up (in Jmol, not in Tachyon).

 

I know nothing about the Jmol code, but

 I don't see how it could be related.  To display a real-time 3d object, Jmol has already solved this, and numerous other intermediate problems  (viewport, data representation, coordinate transforms).  Somewhere in Jmol, a manager/interpreter stands between the solver's output and the displayport methods.

For a 2D plot, there is clearly no interpreter at all.  It's not a bug, it's just logic that doesn't match the structure of what it's trying to do.  For example, the axes might always display correctly, but the parameter "axes" is in the wrong place.

This is confusing because it seems natural to define various properties of the plot inside the plot itself, as many other parameters work in both methods.

--
Andrea Lazzarotto - http://andrealazzarotto.com

 

Can we hang on to these words?  I think they're important.

Defining the properties in that display isn't just natural, it is an accurate logical structure.  Win-win.  Right now (in 2D) there are no graph data to display.  An equation is rendered to an image container, losing all information about the structure of its contents.

It is possible to continue this way.  We can hijack the image format and use, say, Value to define the height of the curve at a given point, and pack the necessary transform information along with it.  This works for static objects, but I think it would be a mistake to use it to build graphs, because equations change shape as you vary the parameters. 

 Vertex list; connection information.  Points, lines, surfaces. We need to manipulate objects composed of these elements, then render the result to the monitor.  This is what we all want, right?

In the long run, there is no reason to differentiate 2D and 3D plots.  A 2D plot has an orthographic camera aligned to one axis.  Say it's aligned to z.  The magnitude of all vectors <0,0,k>, from your point of view is 0.

Or however people normally solve this problem.

I know you all know that.  I'm just reminding you.   There are an awful lot of different plot methods to memorize, and no interpreter-with-display structure to manage them.

[kcrisman]

This is http://trac.sagemath.org/sage_trac/ticket/9708; we would love help fixing this bug.   There is certainly some inconsistency, but this one is unintentional (and who knows, it may have worked a number of years ago).

- kcrisman 

[Andrea Lazzarotto]

2012/7/2 kcrisman <kcri...@gmail.com>

There is certainly some inconsistency, but this one is unintentional

Sorry, I didn't know that. Thank you for linking the bug.

[kcrisman]

On Sunday, July 1, 2012 5:29:43 AM UTC-4, Slumberland wrote:

The grapher has been defined as an image compositor.

Oops.

:)

Symptoms:

-- Render an animated .gif to have an animated graph.

-- show(A + B)     ('plus'?   That's a BLIT.  Also, the syntax is inconsistent.  It changes from "add the functions A and B" precisely where the graph object fails to have any meaningful mathematical input, and instead requires "the composition of A && B".  Complete change of context, at the wrong time.)

-- all the parameters which (should) belong to the grapher are instead duplicated in the various plot() methods.  They overlap, and there are then additional routines to sort out the overlap.  e.g. "show axes", "aspect ratio".

-- Where there are not routines to sort it out, the behavior is equally odd.  If the "xmin" and "xmax" values are different for two plot()  calls, only parts of the function show, when they are added to the same image.  All but one definition of display range is accidentally converted to a function evaluation range.

-- the solve method is not properly separated from the display method.  implicit_plot(), plot(), parametric_plot().  But the coordinate space is, in reality, completely independent of the method used to solve the equation.

Truthfully, your remarks are so cryptic that I am not sure what you are referring to in all of them.  To some extent we do try to keep some methods that are about showing the plot in show() (which I will point out causes no end of confusion to people who just want to plot graphs), but a lot of whatever inconsistencies you are trying to point out is the natural result of taking the original basic functionality and adding methods to it.  If you have the time and expertise to refactor the plot code significantly (keeping backwards compatibility for a season), that would be a valuable contribution.

 

This seems like a situation where Python could maybe benefit from your expertise.  Is it possible to talk to the Python developers about replacing some of the default methods and definitions over time, if they are incorrectly matched to the relationships they are designed to describe?  I can't see how it is possible to realize the desired improvements to Interact, with an image Blitter.   :-(

I don't know what Python has to do with this.  Most of our 2D plot code is custom wraps of matplotlib; there are some exceptions.  If you have suggestions for Python, probably there is a way to do this.