Thanks Maurice and Alan
This is all really worth thinking about for planning this stuff. I would in
general think that a move towards floating point internal
representation would be worthwhile. Some comments on your above comments -
I am probably "teaching my granny to suck eggs" but thought I would mention
them so they are included in the discussion.
Speed using 16 or 32 bit integers should really be equivalent in terms of
calculation speed - the bigger hit will be in terms of memory access. The
biggest hit is going to be in memory reallocation and moving the existing
data whenever the buffer expands. I can't remember right now how that is
done - is extra memory allocated on each reallocation or is "just enough"
memory allocated so that new memory must be allocated for each instruction.
The Microsoft implementation of std::vector doubles the memory allocation
whenever new memory is needed to alleviate that problem.
Also for scaling we will probably get better performance using 32 bit
floats rather than 32 bit integers at least up to the point where the
exponent saturates.
Regarding the "special values" where small errors in floating points lead
to jumps in integer representation - I think this is probably dealt with
now by anti-aliasing in most modern drivers. I think if a user uses a
driver without anti-aliasing then they should expect such problems. I
haven't used the postscript or SVG drivers much as I have generally used
wxWidgets' wxPostscriptDC and wxSVGDC with the wxWidgets driver to achieve
those outputs. Certainly in wxWidgets 3.0 they use decimal representation
to give fractions of a point so there should be no problem with floating
points there - do the PLplot drivers do the same?
Phil
On 11 January 2015 at 00:18, Maurice LeBrun <m...@brownwolf.org> wrote:
> On Saturday, January 10, 2015 at 15:54:23 (-0800) Alan W. Irwin writes:
> > I assume for the purposes of the further discussion that you meant
> > "internal" physical device coordinates but please confirm that (or
> > take the rest of what I say with a grain of salt if that assumption is
> > incorrect).
>
> That's correct.
>
> > The problem with using shorts to represent internal physical
> > coordinates is those 16-bits are not really enough. There are
> > problems with zoom (as mentioned by you above). Also, there are
> > problems for the unzoomed case. For example, we had to fight for
> > years to desensitize our standard examples to floating point rounding
> > issues. The problem was we needed to avoid certain magic numbers
> > where our input PLFLT world coordinates or normalized device
> > coordinates (say for any labels or tick marks) would transform to a
> > position almost exactly between two integers in internal physical
> > coordinates so that a very slight floating-point rounding error in
> > calculated positions would propagate to a substantial visible change
> > in the resulting plot. Because of these known floating-point rounding
> > sensitivity issues, I am also convinced (although I cannot tell for
> > sure because I am used to the current look of PLplot results) that our
> > plots would likely look much smoother if more than 16-bits was used to
> > represent internal physical coordinates.
> >
> > When this internal physical coordinates representation issue was first
> > brought up on the list more than a decade ago as a result of
> > Geoffrey's bad results with zooming, we discussed a number of options.
> > At the time I advocated simply using PLFLT (normally 64-bit floating
> > point) for the type used for internal physical coordinates. Because
> > memory and disk space are cheap now, I see absolutely no fundamental
> > issues with this solution except for the one important issue of plmeta
> > bandwidth where plmeta results that are written in internal physical
> > coordinates would automatically be a factor of 4 larger than the
> > present case where internal physical coordinates are represented as
> > shorts.
> >
> > I think the solution to this dilemma is to typedef a PLINTERNAL type
> > which normally is the same as PLFLT, but for critical plmeta bandwidth
> > cases the user still has the option to build and use a PLplot version
> > that typedefs PLINTERNAL as short.
>
> In association with the zoom issues observed about a decade ago, I had
> work in
> progress to up the device space from 16 bits to 32 bits. This resulted in
> a
> huge improvement in resolution of course, but some surprising side effects,
> such as redraws becoming noticeably slower. I never got around to figuring
> out if this was avoidable -- I was pumping 2x as much data through the plot
> buffer code so maybe not. And in that case maybe it would've been just
> fine.
>
> The real sticking point with the 16->32 bit change (not to mention floating
> point) was the way dashed line draws are done. At least at that time, it
> reeked of suck. The dash segment draw required an iteration over each
> addressable point to find the demarcation point. So it got really slow,
> and any fix might require a rewrite of the dashed line logic.
>
> Aside: we ended up going with a different approach -- handling redraws from
> the client side, which worked out great. But unfortunately I had to
> abandon
> the plplot-side effort due to lack of time.
>
> --
> Maurice LeBrun
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
