Re: The Principle "Everything is an expression"
- To: mathgroup at smc.vnet.net
- Subject: [mg101221] Re: [mg101190] The Principle "Everything is an expression"
- From: "David Park" <djmpark at comcast.net>
- Date: Sat, 27 Jun 2009 06:02:55 -0400 (EDT)
- References: <3227470.1246015000794.JavaMail.root@n11>
Alexey,
I'm not quite certain of the objective of your question, but I suspect it
relates to difficulty in using the WRI graphics paradigm. And that is
because their paradigm is unintuitive and constantly points users in the
wrong direction if they want anything but one of the standard plots.
Old-timers know how to construct their graphics, but even they often stay
away from overly complex custom graphics just because of the complexity.
The principal problem is that WRI initially built their graphics around
"set-piece plot types". If your graphic fits closely into one of these,
everything is fine. Otherwise you have to figure how to screw it around to
get what you want. In regular Mathematica, the standard method for making
custom graphics is to use the Epilog statement to add primitives, and to use
Show to combine various plots. But there are a lot of problems and users
still become confused or discouraged.
The problem with Show is that you can be forced into a lot of graphics level
jumping if you want to combine primitives with plots. Another problem is
that you have to be careful how options are picked up in the Show statement.
The problem with Epilog is that it can become the tail that wags the dog.
Another step in the wrong direction are the drawing tools introduced in
Version 6. At first sight, these seem nice but the problem is that one does
not end with a complete single basic textual specification for the graphic.
If one wants to change some parameter in the set-piece portion of the plot,
then one has to redo all the (unspecified) hand changes with the drawing
tools.
Another confusion for users is the difference between graphics options that
affect the individual items drawn (such as MaxRecursion or Mesh) and options
that affect the overall look of the graphic (such as AspectRatio or
ImageSize). All of this discourages or confuses many users as can be seen
by many questions on MathGroup over the years.
"Everything is an expression" is nice, but a supplemental principle for
graphics should be: "Everything is a graphics primitive". It is that
principle that I implemented as a base part of the Presentations package.
All of the set-piece plot types are replaced by corresponding "Draw"
statements that can be used directly as graphics primitives and mixed with
other primitives such as Circle or Text, and also with graphic Directives.
There are Draw statements for just about every plot type, and there is
provision for using third party plots. With this paradigm one just draws one
thing after another. It is much more intuitive and users appreciate it and
find it easy.
The usage of each of the Draw statements is like the underlying plot type
statement, but its options are only those that affect the production of the
primitives. For example, the options for ParametricPlot are:
Options[ParametricPlot]
{AlignmentPoint -> Center, AspectRatio -> Automatic, Axes -> True,
AxesLabel -> None, AxesOrigin -> Automatic, AxesStyle -> {},
Background -> None, BaselinePosition -> Automatic, BaseStyle -> {},
BoundaryStyle -> Automatic, ColorFunction -> Automatic,
ColorFunctionScaling -> True, ColorOutput -> Automatic,
ContentSelectable -> Automatic, CoordinatesToolOptions -> Automatic,
DisplayFunction :> $DisplayFunction, Epilog -> {},
Evaluated -> Automatic, EvaluationMonitor -> None,
Exclusions -> Automatic, ExclusionsStyle -> None,
FormatType :> TraditionalForm, Frame -> Automatic,
FrameLabel -> None, FrameStyle -> {}, FrameTicks -> Automatic,
FrameTicksStyle -> {}, GridLines -> None, GridLinesStyle -> {},
ImageMargins -> 0., ImagePadding -> All, ImageSize -> Automatic,
ImageSizeRaw -> Automatic, LabelStyle -> {},
MaxRecursion -> Automatic, Mesh -> Automatic,
MeshFunctions -> Automatic, MeshShading -> None,
MeshStyle -> Automatic, Method -> Automatic,
PerformanceGoal :> $PerformanceGoal, PlotLabel -> None,
PlotPoints -> Automatic, PlotRange -> Automatic,
PlotRangeClipping -> True, PlotRangePadding -> Automatic,
PlotRegion -> Automatic, PlotStyle -> Automatic,
PreserveImageOptions -> Automatic, Prolog -> {},
RegionFunction -> (True &), RotateLabel -> True, Ticks -> Automatic,
TicksStyle -> {}, WorkingPrecision -> MachinePrecision}
But the option list for ParametricDraw is much shorter:
Options[ParametricDraw]
{AxesOrigin -> Automatic, BoundaryStyle -> Automatic,
ColorFunction -> Automatic, ColorFunctionScaling -> True,
Evaluated -> Automatic, EvaluationMonitor -> None,
Exclusions -> Automatic, ExclusionsStyle -> None,
MaxRecursion -> Automatic, Mesh -> Automatic,
MeshFunctions -> Automatic, MeshShading -> None,
MeshStyle -> Automatic, Method -> Automatic, PlotPoints -> Automatic,
PlotRange -> Automatic, PlotStyle -> Automatic,
RegionFunction -> (True &), WorkingPrecision -> MachinePrecision,
PerformanceGoal :> $PerformanceGoal}
The custom drawing statement is also much simpler:
Draw2D[
{draw one thing,
draw a second thing,
directive,
draw a third thing,
etc...},
options that affect the overall look]
Another advantage of dealing directly with the primitives is that they are
immediately available for manipulation. It is also possible to generate some
of the primitives in advance and just insert them into the Draw2D statement.
Analogous considerations apply to the Manipulate statement. It is THE
set-piece dynamic presentation and again it is very nice if what you want
fits neatly into it. But, flexible as it is, most custom dynamic
presentations won't and it is much easier to write your own custom dynamic
presentations. In the PlaneGeometry section of Presentations I show a simple
method for doing this applied to dynamic geometric diagrams. In a Draw2D
statement it is easy to apply Dynamic to just the specific items that are
changing. I've posted a few examples of this on MathGroup in the past.
David Park
djmpark at comcast.net
http://home.comcast.net/~djmpark/
From: Alexey [mailto:lehin.p at gmail.com]
Hello,
I think that the underlying principle "Everything is an expression" in
Mathematica is great and is one of the most exciting advantages of the
Mathematica system.
But it is disappointing that this principle is still fails even on
such basic example as representation of a simple Plot. Consider the
following:
g = Plot[Sin[x], {x, 0.2, 10}]
Show[FullGraphics[g], AspectRatio -> 1/GoldenRatio]
It is clear that the two generated images are significantly different.
This means that the function FullGraphics[] does not gives the true
expression-representation of the first plot. Is it true that in really
we can not get the true representation of the plot as an expression?
And the principle mentioned really fails even on this? Or there is
another way to get it?
Thank you for your attention a priori.