Okay then, so from all the various discussions I get the impression that
the consensus is
1) The easiest way to get the buffer into/out of PLplot would be to add a
command line option (e.g. -mfo filename and mfi filename) and have plplot
core code pick this up and write to/from it. this requires no propagation
to additional languages and ensures the
2) The file will consist of a header that will include a plplot identifier,
a file format version number, a flag for endianness, the size of the type
used for the coordinates (with the assumption that if this is ever
increased to 32 bit then it will become a real rather than an int) and the
type of float used (e.g. 32 bit ieee). The file will then simply consist of
a dump of the buffer.
3) In the future the buffer should be updated (probably internally and for
the file) so that each command is prepended with the size of the command.
This will allow new commands to be added or bugs to be fixed and still
allow reading of the buffer by older software versions.
4) In the future the buffer could be written to a memory mapped file,
perhaps by some known prefix to the file name or something. This will
significantly increase speed for real time communication between processes
reading/writing the buffer.
5) For now it seems sufficient to simply support reading/writing in native
format, but in future we would introduce conversion from various file
endianness and float formats into native format during reading.
Does this sound sensible?
I did some more work on the wxWidgets driver over the weekend and am
basically at a point where until this mechanism is sorted I can't really do
much more, unless I write a wxWidget driver specific version of this
transport mechanism and then we generalise it to plplot core code later.
The alternative is that we forget this as a general idea and I just
implement something for wxWidgets myself.
Phil
On 11 January 2015 at 19:41, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:
> On 2015-01-11 09:27-0000 Phil Rosenberg wrote:
>
> 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.
>>
>
> No, it is worse than that. Generally, we have PLFLT input which is
> transformed to internal physical coordinates which are then
> transformed again (usually by simple scaling) by device drivers into
> the actual physical coordinates (pixels or whatever) that driver
> understands. So for certain magical combinations of input (which our
> standard examples used to hit a lot), the internal physical coordinates
> which are currently represented as 16-bit integers can flip to a
> different integer causing a section of the whole plot to shift visibly
> relative to the rest depending on platform. (Here we are defining
> platform as the combination of computer language, optimization for
> that language, OS, and hardware).
>
> In other words, the devices are following the orders they are given
> (with or without antialiasing applied) by the internal physical
> coordinates, but for magic input values those orders get changed by
> +/- 1 integer out of the limited total range of 16-bit integers
> depending on platform. We have historically adjusted our standard
> examples to avoid these magic situations so that we get more
> consistent test results comparing one platform with another. But that
> is just a cover up, and I would far prefer our internal physical
> coordinates simply had a lot more resolution so that in full
> generality regardless of input values the PLplot results always look
> the same (with small rounding errors consistent with 64-bit doubles
> rather than much larger and visible rounding errors consistent with
> 16-bit integers) from one platform to the next.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
vanity: www.gigenet.com
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
