Proposal for I/O in P1788 (M0017)
(1) I found the C examples quite useful for the purpose of explaining
what is going on, but I briefly cringed when I saw an example
where both bounds were handled in a single fprintf() invocation.
Then I realised that the format was "%s %s" -- no actual conversion.
This is in section 3.3.1 of JDP_IO_ProposalV2.pdf.
I wonder if it would be appropriate to include a warning that the usual
C printf() and scanf()/strtod() functions don't include rounding control.
That's why a single sprintf(buf, "[%.16e %.16e]", xx.inf, xx.sup) could
not be used: one needs separate sprinf() invocations, each preceded with
an appropriate fesetround() invocation.
(2) The notion of "recovery conversion". At the end of 3.4.2 (in the
"Constraints" section), it is stated that one can recover from
outward rounding when one knows that the input was the result of
sufficient-precision output conversion.
Indeed, such an input conversion should be conducted using inward rounding.
So (a) I think we need to define such an input conversion, and (b) we might
name it "recovery conversion".
Now, what if the input to a recovery conversion does NOT satisfy the
assumption? Well, it could be verified by converting the result back
to text format with the requisite format-derived precision -- but there
are many equivalent text formats, and even the precision of the input
might have been higher than the required minimum. So this cross-check
would not be trivial at all.
The reasoning above suggests that we should simply define inward-rounding
conversions, and describe their purpose, leaving the verification of
applicability to the programmer. After all, external constraints may
well be ensuring that the assumptions are fulfilled, so back-conversion
would be a waste of time.
Michel.
P.S. The reason inward rounding works for recovery conversion is that
if a conversion was exact, it will be exact in both directions,
and if it was inexact, we know that the input and output roundings
were strictly complementary. This all under the assumption that
the effective output precision was higher than the effective
input precision. For example, if the binary format is Binary64,
the decimal precision would have to be at least 17 for decimal
output, and at most 15 for decimal input. This last case could
arise when decimal intervals managed by a program were to be
stored externally as Binary64 for some reason.
---Sent: 2010-05-17 18:10:24 UTC