# Effects of single-point and multi-point calls of Point on plot range

Several Graphics primitives are listable. For instance, Point accepts lists of coordinates so that multiple calls to Point are often unnecessary.

The results are the same, except for one thing I noticed while working on the eye fixation question, yesterday.

pts = RandomReal[10, {30, 2}];
pl1 = Graphics[Point@pts];    (* single Point function call    *)
pl2 = Graphics[Point /@ pts]; (* multiple Point function calls *)

GraphicsRow[{pl1, pl2}, Frame -> All]


The difference lies in the effect on PlotRange. Whereas a list of Points yields a PlotRange of:

AbsoluteOptions[pl2, PlotRange]

(*
==> {PlotRange -> {{0.493385472, 9.588596333}, {0.2849334536, 9.012342799}}}
*)


using the multi-Point syntax gives:

AbsoluteOptions[pl1, PlotRange]

(*
==> {PlotRange -> {{0., 1.}, {0., 1.}}}
*)


The Get Coordinates tool gets the same coordinates in both figures.

The question is: is there any good reason for the PlotRange reported in pl1 or is this a bug?

-
It's half the extents of the min-max of the individual points... not sure why though. –  rm -rf Mar 8 '12 at 22:59
@r.m The points lie in a range of 0-10. What do you mean with individual min- max extent? –  Sjoerd C. de Vries Mar 8 '12 at 23:02
Graphics plots each point (if you plotted one by one) such that it is centered in the entire plot. So if you do it individually and calculate the PlotRange for each, then I would expect that if you Show[] all of them, the plot range would span the minimum and maximum among all the individual ones. So far this is good. However, what you see is exactly half of that. I can't explain for this factor of 2 though. Try: xylims = (Last /@ FullOptions[Graphics[Point@#], PlotRange] &) /@ pts; Through[{Min, Max}@#] & /@ (xylims\[Transpose]). This final number is twice the plot range for pl2 –  rm -rf Mar 8 '12 at 23:09
It's a bug, that has been reported once or twice already. –  Brett Champion Mar 9 '12 at 3:57
Using Complement[Union[FullOptions[pl2], FullOptions[pl1]], Intersection[FullOptions[pl2], FullOptions[pl1]]] you find there are additional options that differ between pl1 and pl2:AspectRatio,AxesOrigin, and Ticks. –  kguler Mar 9 '12 at 4:25
show 7 more comments

I'm tempted to blame this on AbsoluteOptions, because it is known to be buggy (I filed a bug report on it in January). I also tried the following

FullGraphics@Show[pl1, Frame -> True]


which shows that the incorrect PlotRange value is in fact used internally, making this a pretty significant bug.

I would suggest filing a bug report blaming it on AbsoluteOptions (it's just a guess, but hey - we don't have the source code...)

Update

I think the case against AbsoluteOptions is becoming stronger with the following tests. That means, I'm now pretty confident that the issue in this question is not inherent to the argument-list version of Point.

Consider the three-dimensional version of the question, with

pts = RandomReal[10, {30, 3}];
pl1 = Graphics3D[Point@pts];
pl2 = Graphics3D[Point /@ pts];


The results of AbsoluteOptions[pl1, PlotRange] and AbsoluteOptions[pl2, PlotRange] show the same discrepancy as in the 2D case.

If I now replace the 3D points by spheres, I can use the same two methods of feeding it the points:

sph1 = Graphics3D[Sphere[pts, .05]];
sph2 = Graphics3D[Sphere[#, .05] & /@ pts];


However, the results of

AbsoluteOptions[sph1, PlotRange]


and

AbsoluteOptions[sph2, PlotRange]


now both show the incorrect result {PlotRange -> {{0., 1.}, {0., 1.}, {0., 1.}}}. What I would infer from this is that it is not the listability property itself that is causing a wrong PlotRange calculation. Note: I say "infer" - not "conclude", because it's not conclusive...

Update 2

For completeness, I sent a bug report to Wolfram in which I gave these examples and stated that AbsoluteOptions doesn't work properly here. Wolfram support confirmed the bug.

-