Re: [Plplot-devel] PLplot representation fidelity

[Alan W. I. <ir...@be...>]

On Mon, 8 Apr 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > I do have some further (perhaps naive) comments.  I wouldn't worry a bit
>  > about increasing the size of the metafile by a factor of four (assuming we
>  > use 64-bit which is what I hope we do).  Disk space and band width are
>  > incredibly cheap now, and the historical trends say they will get a lot
>  > cheaper in the future. It still blows my mind that the 2GB scsi disk I
>  > bought in 1996 cost me $1700.  Now, 2GB of ATA disk space can be had for
>  > $10.
>
> Well, we do tend to see some monstrously large metafiles even now, and as
> Maurice mentioned, long haul networking to remote computational sites can
> make this as much of an issue as the disk space requirement itself.  I wonder
> how well gzip or bzip2 would be able to compress a file made up of lots of
> binary 64 bit integers with lots of zero bits mixed in.
>
> Whatever we chose, the code API's will all have to use the same size values
> for passing things around between functions, but the plmeta driver could
> narrow it down to a chosen (run time selectable) bit width before writing it
> out to disk.  I'm okay with this, sounds like Maurice is too.

Yes, that sounds like a good solution in those situations where you are
bandwidth limited.

>
> One question I have is, is there a way to specify a 64 bit integer on a 32
> bit machine, that is legal ANSI C?  I don't think so.  If I remember
> correctly, long long might be 64 bits in GCC/Linux, but it's not in ANSI C.

I confirmed 64 bits for GCC long long before I posted, but I don't know
whether modern ANSI supports it or not. There were a number of comments in
e-mail lists found by a google search of ansi long long.  The gist was
"Unfortunately, the ANSI definition of C doesn't yet include 'long long'"
which implies they might support it in due course.  Does anybody have the
definitive ansi link that discusses long long?

In any case, a large majority of our users do have gcc so long long should be
allowed as a configurable option for at least that case or to put it in terms
of the proposal above, it should be one of the run-time selectable options
if the compiler supports it.

>  > Also, it sounds to me that your present difficulties are because integers
>  > lack dynamic range. Would it be possible to get around that limitation by
>  > switching to (64-bit) floating point instead?
>
> Well, note that scaled integers of any particular size have more dynamic
> range than a float of the same size.

Agreed.  However, right now are we using scaled integers or just integers?
You really have to be careful with scaled integers that you don't have
integer overflows.  So if we don't currently have scaled integers, we might
want to use floats (of sufficient precision) instead in the interest of
simplicity.  But if the coding for scaled integers can be straightforwardly
arranged to avoid integer overflow (or if that is what we do already), then
obviously that is the best solution.

Alan