Talk:Graph Object Wishlist

Hi Darwyn,

Looks good to me. I think we need a more general specification for ""labels" and "stamps". These are text or images that appear in the graph at specified position.

I use them to implement the open and filled circles in piecewise graphs, and also as labels of points "a", "b". They can also be used to plot discrete data. It would be nice if the text could include math symbols such as \alpha.

One "label" you refer to might be called a "legend" or "caption" or "title" for the entire graph. There are also labels for axes, but not in general.

references:

http://webwork.maa.org/doc/cvs/pg_HEAD/lib/Label.html
http://webwork.maa.org/doc/cvs/pg_HEAD/lib/WWPlot.html see section "fn, lb, stamps"
          

Your thoughts? -- Mike

Darwyn

Mike, The labels are handled by string objects. I think this adds the benefit of having labels that can be "texed", like being able to label the graph of a trig function with multiples of pi. Of course that probably means more work for Davide.

The stamps would be circle objects. It might be a good idea to define the default radius of a circle so that it will appear as a stamp, circle objects can be filled or not.

This can be included in the graph of a function by putting the function, string, and circle all in a list object.

It might be appropriate to add in a method for invoking a certain type of graphing routine, in particular invoking a flash applet as opposed to the built in wwplot. I didn't add this functionality to the specs, waiting for input from the flash applets group.

Mike 12/4/2008

Thanks to everyone who participated in the video conference yesterday. I'd like to record my view of two points here:

• "strings"
  • the term Strings is too general and too much of a programming term. Using it both as a Context item for answer checkers in MathObjects and in GraphObjects is going to cause confusion.
  • I propose "Label" for the GraphObject above -- a textual image that appears in a graph. It has attributes of position and justification. Allowing TeX generated images is also possible.
  • "Stamp" is what I use before for any image that had a position. -- certainly implementation code can be shared between Label and Stamp and perhaps there is no need of separate Stamp term -- just allow Labels to accept images, Circles, Polygons, and any thing else that generates an image.
  • While I'm at it I'd like to find a better word for String objects (MathObjects version) as well. I suggest "Word" or "Phrase", Paul suggested "MathString", as in "allowable word" or "allowable phrase" -- those phrases that make sense in the current context.

I think String is the MathObject that currently causes the most confusion about how it behaves.

Context()->phrases->add("does not exist"=>{}); or
Context()->words->add(dne=>{});

• graphs/canvas
  • I do like this approach in which everything knows how to "draw" itself but sometimes I'd also like direct access to a container

in which to draw. I propose adding a Graph of object for this, or perhaps Canvas would be a better term. Mostly the Canvas object would be called behind the scenes but it would be available for direct access when necessary.

Comments on the proposal

I like the use of List object as the container for graphs.

It is a bad idea to use String objects for labels, since they require the string to be added to the Context, and that makes the string available in student answers, which probably is not what you want. There should probably be a Label() object that is a string without the requirement that it be in the context.

Syntax problems: $x->{y=>z} should be $x->{y} = $z. You can also use Formula("...")->with(y=>z,...) or $x = $x->with(y=>z,...).

E.g., $graph = List($f1,$f2,String("Piecewise Defined")->with(position=>"header"));

Note that z may need quotation marks if it is a string constant: Something like $title->{position=>header} should be $title->{position} = "header";

Note: There is a PiecewiseFunction math object that could also be used.

You propose Circle and RegularPolygon as new types. Also should have Rectangle? Line? I might suggest Graph::Circle, Graph::RegularPolygon, etc.

For option size: "filesize" is probably a bad name (since it could be confused with storage space). "pixels" might be better.

I'm not sure I understand the texsize parameter. I would like to see two controls: a scaling factor to produce a new image at a higher resolution (for printing) and a scaling factor for use within the TeX document (perhaps relative to the \hsize?)

For option Axes: What does "the point of intersection of the two axes" mean? Are these within the coordinate space of the graph, or the pixel space of the image? (I.e., if the point is (10,5), does that mean that a vertical axis is drawn at x=10 and a horizontal one at y=5 within the coordinate space of the graph, or does it mean that the origin (0,0) is at 10 pixels in from the left of the image and 5 down from the top (or up from the bottom) of the image?) You may need controls for both.

Ticks might want to be specified as a delta as well.

Specifying fonts might be problematic. Not sure what fonts the system has.

For circles, the center and radius should be part of the object. (This is what $r->{center} and $r->{radius} will be anyway.) You can always change them once the object is set up, but just as a Real is a specific real, a Circle should be a specific circle.

You may also want to specify circles by bounding box?

For Formulas, not sure test_points and num_points are the right things for this. They are used for answer checking, and appropriate settings for them are not appropriate for graphing. E.g., num_points is usually 3. Might use plot_points, for example.

Should functions of two variables produce 3D plots using LiveGraphics3D (or something similar)? What about functions that produce points? Should they produce parametric plots?

ImplicitEquation is really only experimental, but could be used for this. I'm not sure what test_points and num_points will do in this case. Depending on the algorithm used to determine the implicit curves, they might or might not be useful. Do you want to have multiple levels (e.g., f(x,y) = k for different values of k?) Should you be able to color (or shade) the regions between? I think there need to be more options, here.

Intervals: graphics might want their own Context settings (not just flags). If not, "delimiters" is probably not descriptive enough. Perhaps GraphicDelimiters?

Points: Not sure "delimiter" is the right name for this. Perhaps "PointMark"? If you use "delimiters" for everything, you can't use the Context flag for this, as the different classes have different values that the delimiter can take.

The Set object is a finite set of Reals, so it should be the same as the graph of a list of Reals.

For Unions, it seems to me that the Interval options would override the Union options, if they are present, rather than taking the options from the last one.

For Vector: the use of limits is incompatible with the internal use of limits when the vector is parametric. (Note that this produces a Formula object anyway, so it is not a Vector object, and so should fall under the Formula catergory). This suggests that you may want to use "axesLimits" (or something similar) rather than "limits" throughout. Since limits are used in answer checking, and may not correspond to the appropriate visual limits, that might be a good idea anyway.

Davide