Re: [Psidev-ms-dev] Why base64?

[Angel P. <an...@ma...>]

I guess I am using "lossy" too loosely (say that 10 time fast). I meant 
that the conversion of a double or single decimal to the significant 
figures with respect to the limit of instrument detection we all know 
and love to see in plain text formats is a lossy translation. I was not 
implying that going from byte strings to the equivalent ascii 
translation was a lossy operation. Sorry for the confusion.

But send me the C code and I will post it on the docstore.

-angel




Mike Coleman wrote:
> Another way to send the value is to send an ASCII representation of a
> decimal number that will, upon being converted using strtof(3), result
> in the identical single-precision value.  (That decimal number is
> *not* typically mathematically equal to the single-precision value,
> it's just closer to it than to any other single-precision value.)
>
> This really *is* a completely lossless representation.
>
> There are different ways to generate these decimal numbers.  It is
> sufficient (if not necessarily optimal) to simply use printf(3) with
> sufficient precision (e.g., "%.8e").  This will work with
> implementations that do correct rounding.  Linux (meaning GNU libc)
> has done this correctly since at least nine years ago--I would assume
> the vendors are doing it right, though this should be confirmed.
>
> I'm including a small C program that demonstrates what I'm talking
> about.  It does an exhaustive check for the single-precision case.  It
> takes a couple of hours to complete, but if you're going to see an
> error, it will probably occur pretty quickly.  (If you see any errors,
> I'd like to know.)
>
> This doesn't change the fact that 0.1 doesn't have an exact IEEE 754
> representation.  That is a separate issue (and one that a base64
> encoding does not address either).
>