Re: NSKeyedArchiver and NSPoints
Re: NSKeyedArchiver and NSPoints
- Subject: Re: NSKeyedArchiver and NSPoints
- From: Michael Ash <email@hidden>
- Date: Wed, 28 Apr 2010 23:49:20 -0400
On Wed, Apr 28, 2010 at 3:31 PM, Quincey Morris
<email@hidden> wrote:
> On Apr 28, 2010, at 11:42, Kyle Sluder wrote:
>
>> Er? Unless there's some documentation about the precision of
>> NSStringFromPoint being less than that of the members,
>> NSStringFromPoint could certainly include just as much precision as
>> the actual float.
>
> Assuming that the string contains a decimal floating point number, then both the conversion to and from binary floating point involve (in general) imprecision from rounding and/or truncation, since in both cases the result could theoretically require an infinite number of decimal or binary places.
>
> Keep in mind there are some binary floating point numbers with a finite number of bits that have no exact representation in any finite decimal string, and vice versa. It's certainly true that since both representations are finite, then with enough decimal digits you could get very close (no more error than 1 in the last binary digit), but very close is not the same as exact.
Actually, while there are finite decimal numbers with no finite binary
representation, the reverse is not true. Every binary number can be
represented by a finite number of decimal digits. I believe this is
because 2 is a factor of 10. To prove it to yourself, just take
successive negative powers of two and notice how you never get a
repeating decimal. The fractional part of a binary float is just a sum
of various negative powers of two, and if the individual components
are finite, the result must be as well.
And very close is the same as exact in this scenario. You don't have
to have precisely the same representation, you just need to have a
representation which is closer to the original value than to any other
representable value. When decoding, there is no ambiguity, and the
original value can be reproduced exactly.
> Even if you could get back the original binary value by using enough decimal digits, you'd still need to be certain that the binary to string conversion in the frameworks was just that finicky (as opposed to, say, using a library routine that defaults to a smallish maximum number of significant digits).
This one is the key. Storing floats as strings is completely doable
and not at all troublesome, but unless you know the frameworks are
doing it right, you can't count on the round trip preserving
precision. And apparently it doesn't, as another thread participant
pointed out.
> Plus, you'd have to expect that encoding doubles would require, in the worst case, at least 309 significant digits, which is a much longer string than I want in my archive.
I think you've flipped your math around somewhere here. A double has
54 bits of mantissa (53 in the value itself, and an implicit leading
1), which means you need 54 binary digits to write that mantissa. You
need *fewer* decimal digits to write the equivalent number. The
precise ratio is the log base 2 of 10, which works out to a little
over 16 decimal digits. Fractional digits are hard to come by, so call
it 17.
If you're worried about very large or very small values, you can use
scientific notation and encode the exponent as well. There are 11 bits
of exponent, which works out to 4 decimal digits. Add the 'e' for
scientific notation, the '.' for the decimal point, and potentially
one '-' on the mantissa and another on the exponent, and your worst
case is 25 characters. Assuming ASCII (or UTF-8 or whatever), this is
only about 3 times larger than the 8 byte native representation, and
not too bad considering that representing a 64-bit quantity in base 10
requires up to 20 digits.
> So my original point stands: I want my original bit pattern back again after unarchiving, and I don't believe that a finite decimal string will guarantee that.
Storing decimals as strings is inefficient and possibly error-prone,
but it's not inherently lossy or even impractical.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden