Re: Level 2 query, number 2
George Corliss wrote:
> So it appears that the inward rounding might be done on the SOURCE side,
> rather than on the TARGET side, as Michel had suggested? Either could
> work, as long as the standard specifies. I think I could make a case
> for either.
There are in fact three possibilities -- but they all have this in common:
Conversion for the purpose of import/export is DIFFERENT from conversion
from one interval type to another, if the mapping is not exact. I had
listed two (outward for export/inward for import, or to-nearest each way);
George just proposed a third, which permits the import conversion to be
normal interval conversion (outward rounding).
The problem with this, as with to-nearest both ways, is that the exported
text MUST be flagged as having been exported solely for the purpose of
import, whereas with my choice (recovery conversion) only the importer
needs to know that the item was exported, so that inward-rounding recovery
(to the original format, otherwise it is not legitimate) is legitimate.
Baker is right: we should insist on an exact export format (which will
depend on the internal-format radix) so as to avoid the issue entirely.
Any inexact export representation can only recover the original format;
it cannot ever be converted (not even with outward rounding) to another
interval format: this suggests that it MUST be accompanied by original
format parameters.
This really only leaves two practical solutions:
(1) Export EXACTLY
(2) Always round outwards when converting
The two can of course be used together, in which case import back
to the original format will be lossless, as desired.
Michel.
P.S. The sufficient-precision rules for lossless round-trip conversion in
general only apply for round-to-nearest in each direction, and are
thus problematic for interval conversions unless additional steps
are taken, involving extra information about the source format.
---Sent: 2011-09-05 03:24:37 UTC