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. 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). 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. 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. Disclaimer: Numerical Computation was my second-most-hated class in school, so I claim no expertise, but I believe the above claims about conversions are true. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
