Graphics and DisplayFunction

[replic...@gmail.com]

Does anyone know why the following code fails to return the second
Graphics object?

ListPlot[{1, 2, 3}, DisplayFunction -> Print];
Graphics[{Circle[]}, DisplayFunction -> Print];

Even the coloring of the syntax differs for the two: after ListPlot
[...], the semicolon is red indicating its unnecessary presence, while
the one after Graphics[...] is left black. I would think that with the
generalized input of Mathematica 6, the two would behave the same way,
but apparently they do not.
I know how to solve this with Show. I just simply don't understand why
these two behave differently, if both produce (without specifying
DisplayFunction) Graphics objects:

In[104]:= Print[InputForm[ListPlot[{1, 2, 3}]]];
Print[InputForm[Graphics[{Circle[]}]]];

During evaluation of In[104]:= Graphics[{Hue[0.67, 0.6, 0.6], Point
[{{1., 1.}, {2., 2.}, {3., 3.}}]}, {AspectRatio -> GoldenRatio^(-1),
Axes -> True, AxesOrigin -> {0, Automatic}, PlotRange -> Automatic,
PlotRangeClipping -> True}]

During evaluation of In[104]:= Graphics[{Circle[{0, 0}]}]

In[106]:= Head[ListPlot[{1, 2, 3}]]
Head[Graphics[{Circle[]}]]

Out[106]= Graphics

Out[107]= Graphics

Any idea?

[Szabolcs Horvát]

As you said, both produce Graphics expressions. (More precisely,
Graphics *is* a Graphics expression.) But there's a difference: while
Graphics[] is just a way to *represent* graphics, plotting functions
also have a side effect of *displaying* the graphics expressions that
they produce.

In Mathematica <= 5.2 it worked like this: Graphics expressions were
formatted in the front end as --Graphics--, and they could be rendered
with Show[] (which called a function specified in DisplayFunction)

In Mathematica >= 6, Graphics expressions are formatted as the actual
picture they represent (in StandardForm/TranditionalForm). Apart from
this, everything works the same as in 5.2. Of course since the graphics
are formatted nicely in the front end, there's no need for displaying
them in an explicit way, so $DisplayFunction === Identity by default.

But suppose now that you can't/don't use the front end for some reason,
or use an alternative front end. Now it does make sense to use an
explicit command for showing the graphics. Try opening the command line
version, and type <<Terminal` or <<JavaGraphics`.

The reason for the semicolon not being highlighted after Graphics[]; is
that in 5.2 no one typed Graphics[...] expecting to get a plot, but
using Plot[...]; was quite common (to suppress displaying the return
value, --Graphics--)

[replic...@gmail.com]

Thanks for the answer Szabolcs,

Ok, so if I understand it correctly then by using explicit
DisplayFunctions, I display the *thing*, that is the side effect of
the actual function. Obviously only things that are enclosed in Show
can be thus displayed with DisplayFunctions, and - however it's just a
guess - the various plot functions all utilize an internal Show which
encloses their internal graphics. Thus - secondarily - DisplayFunction
can be used with plotting functions as well. But then I simply don't
understand why DisplayFunction is an option for Graphics? Neither

Graphics[Circle[], DisplayFunction -> Identity]

nor

Graphics[Circle[], DisplayFunction -> Print];

work as I would expect. I understand, that

ListPlot[{1, 2, 3}, DisplayFunction -> Identity]

is displayed because of the sideeffect, that is NOT suppressed by a
semicolon, while

ListPlot[{1, 2, 3}, DisplayFunction -> Print];

displays the plot because of DisplayFunction Prints the sideeffect,
that is otherwise suppressed by the semicolon.

Still I don't understand why DisplayFunction does not work on Graphics
as would be - for me - logical. Is this side-effect thing a frozen
suboptimal situation of the pre6 era (which I'm quite familiar with,
however I've never realized this difference, probably because I've
managed to live without ever need to use Graphics directly), which WRI
does not want to change?

Istvan

Szabolcs Horv=E1t wrote:
>
> As you said, both produce Graphics expressions. (More precisely, Graphics=
*is* a Graphics expression.) But there's a difference: while Graphics[] i=
s just a way to *represent* graphics, plotting functions also have a side e=

ffect of *displaying* the graphics expressions that they produce.
>

> In Mathematica <= 5.2 it worked like this: Graphics expressions were fo=
rmatted in the front end as --Graphics--, and they could be rendered with S=

how[] (which called a function specified in DisplayFunction)
>

> In Mathematica >= 6, Graphics expressions are formatted as the actual p=
icture they represent (in StandardForm/TranditionalForm). Apart from this,=
everything works the same as in 5.2. Of course since the graphics are for=
matted nicely in the front end, there's no need for displaying them in an e=

xplicit way, so $DisplayFunction === Identity by default.
>

> But suppose now that you can't/don't use the front end for some reason, o=
r use an alternative front end. Now it does make sense to use an explicit =
command for showing the graphics. Try opening the command line version, an=

d type <<Terminal` or <<JavaGraphics`.
>

> The reason for the semicolon not being highlighted after Graphics[]; is t=
hat in 5.2 no one typed Graphics[...] expecting to get a plot, but using Pl=
ot[...]; was quite common (to suppress displaying the return value, --Graph=
ics--)
>

[John Fultz]

You have it basically right in identifying it as legacy behavior. Since
DisplayFunction is generally irrelevant in the modern graphical world, there's
been no real cause to reinvent it. Preserving its behavior makes it simpler to
make legacy code work when you're running in the legacy graphics mode (i.e.
having evaluated <<Version5`Graphics` ).

Sincerely,

John Fultz
jfu...@wolfram.com
User Interface Group
Wolfram Research, Inc.

> *is* a Graphics expression.) But there's a difference: while Graphics[]

> is just a way to *represent* graphics, plotting functions also have a
> side effect of *displaying* the graphics expressions that they produce.

>
> In Mathematica <= 5.2 it worked like this: Graphics expressions were

> formatted in the front end as --Graphics--, and they could be rendered
> with Show[] (which called a function specified in DisplayFunction)

>
> In Mathematica >= 6, Graphics expressions are formatted as the actual p=
> icture they represent (in StandardForm/TranditionalForm). Apart from

> this, everything works the same as in 5.2. Of course since the graphics
> are formatted nicely in the front end, there's no need for displaying
> them in an explicit way, so $DisplayFunction === Identity by default.

>
> But suppose now that you can't/don't use the front end for some reason,

> or use an alternative front end. Now it does make sense to use an
> explicit command for showing the graphics. Try opening the command line
> version, and type <<Terminal` or <<JavaGraphics`.

>
> The reason for the semicolon not being highlighted after Graphics[]; is

> that in 5.2 no one typed Graphics[...] expecting to get a plot, but using
> Plot[...]; was quite common (to suppress displaying the return value, --
> Graphics--)

[David Bailey]

replic...@gmail.com wrote:
> Thanks for the answer Szabolcs,
>
> Ok, so if I understand it correctly then by using explicit
> DisplayFunctions, I display the *thing*, that is the side effect of
> the actual function. Obviously only things that are enclosed in Show
> can be thus displayed with DisplayFunctions, and - however it's just a
> guess - the various plot functions all utilize an internal Show which
> encloses their internal graphics. Thus - secondarily - DisplayFunction
> can be used with plotting functions as well. But then I simply don't
> understand why DisplayFunction is an option for Graphics? Neither
>

I would forget about the DisplayFunction option - it is more or less
obsolete. Just think of graphics as output - just like numbers or equations.

If you do a calculation, and then as the last step generate a graphical
output (either explicitly with Graphics, or indirectly using Plot (say),
then providing you don't terminate that command with a semicolon, you
will get your graphical output, for example:

xx = 10;
yy = 20;
Graphics[{Line[{{-xx/2, 0}, {xx/2, 0}}],
Line[{{0, -yy/2}, {0, yy/2}}]}]

If, however, you want to go on and calculate something else (or make
another graph), simply print your graphical output (again, exactly as
you would for text):

xx = 10;
yy = 20;
Print[Graphics[{Line[{{-xx/2, 0}, {xx/2, 0}}],
Line[{{0, -yy/2}, {0, yy/2}}]}]];
Print["Something else ",Sqrt[xx]];

[replic...@gmail.com]

Of course one can forget about DisplayFunction and use Print, but for
me a more elaborate function does the job:
Since I have plotting functions deeply embedded in code and in
packages (and for other reasons), I actually have to maintain a
DisplayFunction, which - through user-defined switches - redirects
results to various outputs, possibly not just to the actual notebook,
but simultaneously to notebook AND multiple files as well.
Also a problem with your method is that by Printing a Graphics, you
end up with something that is NOT a Graphics object, but in my case (I
don't want to get to the complex details) I definitely need something
in return that is a Graphics object. I have everything working for
years now, just this bit (the topic, i.e. Graphics are not affected by
DisplayFunction) caused some malfunctions in the previous days.

Thanks for the answers anyway.

Istvan

On Apr 3, 11:11 am, David Bailey <d...@removedbailey.co.uk> wrote:
>
> I would forget about the DisplayFunction option - it is more or less

> obsolete. Just think of graphics as output - just like numbers or equatio=

[mark mcclure]

On Apr 3, 5:11 am, David Bailey <d...@removedbailey.co.uk> wrote:
> I would forget about the DisplayFunction option - it is more or
> less obsolete.

If DisplayFunction -> f is used as an option to a Plot function
or Show, then f is applied to the result. Since the default
value of DisplayFunction is $DisplayFunction, this makes
$DisplayFunction something like $Post for graphical commands.
This can be quite handy. Here are three example settings for
$DisplayFunction.

* Create a tooltip when hovering over a graph:
$DisplayFunction = Tooltip[#, "On graph!"] &;

* Show graph and also auto-export to a file:
cnt = 0;
$DisplayFunction = (
Export["pic" <> ToString[++cnt] <> ".png",#]; #
)&;

* Send graphics to another program:
df[g_] := Module[
{strm},
strm = OpenWrite["!open -f -a /Applications/Preview.app"];
WriteString[strm, ExportString[g, "EPS"]];
Close[strm]
];
$DisplayFunction = df;

After defining $DisplayFunction by entering any of these
commands, simply enter a graphical command, like
Plot[x^2, {x,-2,2}], to see it in action. The last
example is set up to pipe the output to Preview.app on the
Mac, but I suppose that something similar would work on the
PC. This last one is most interesting if you're running a
text based interface, like the Mac Terminal. To get it to
work in that context you need to install a front end as well
by first entering:
Developer`InstallFrontEnd[];
I actually do this frequently when manipulating Mathematica
from other programs.

So, have fun with DisplayFunction,
Mark McClure

[replic...@gmail.com]

Of course one can forget about DisplayFunction and use Print, but for
me a more elaborate function does the job:
Since I have plotting functions deeply embedded in code and in
packages (and for other reasons), I actually have to maintain a
DisplayFunction, which - through user-defined switches - redirects
results to various outputs, possibly not just to the actual notebook,
but simultaneously to notebook AND multiple files as well.
Also a problem with your method is that by Printing a Graphics, you
end up with something that is NOT a Graphics object, but in my case (I
don't want to get to the complex details) I definitely need something
in return that is a Graphics object. I have everything working for
years now, just this bit (the topic, i.e. Graphics are not affected by
DisplayFunction) caused some malfunctions in the previous days.

Thanks for the answers anyway.

Istvan

On Apr 3, 11:11 am, David Bailey <d...@removedbailey.co.uk> wrote:
>
> I would forget about the DisplayFunction option - it is more or less

[mark mcclure]

On Apr 3, 5:11 am, David Bailey <d...@removedbailey.co.uk> wrote:
> I would forget about the DisplayFunction option - it is more or
> less obsolete.

If DisplayFunction -> f is used as an option to a Plot function