Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: P1788 input/output



On 2013-07-22 15:55:53 +0100, John Pryce wrote:
> On 2013 Jul 22, at 09:36, Vincent Lefevre wrote:
> > On 2013-07-19 20:57:20 +0100, John Pryce wrote:
> >> On 2013 Jun 28, at 13:18, Vincent Lefevre wrote:
> >>> ...If we don't plan to specify free-form output (I don't think we should,
> >>> as this must remain language-defined or implementation-defined, IMHO),
> >>> then we don't need it: this is just a language matter. You can mention
> >>> that in a footnote.
> >> Why shouldn't we? Maybe there's a misunderstanding, "free-form"
> >> isn't the correct word? But IMO we need a "vanilla" way to turn an
> >> interval to an interval literal.
> > Well, it depends on what you propose...
> 
> E.g., outputting it in inf-sup from using %g conversion on each bound. E.g. if xx is (a good approximation of) [\pi/1000,\pi], the vanilla form interval2text(xx) might give the string
>   "[3.1415e-3, 3.1416]"
> (If %g defaults to 5 sig figs; I forget.)

In C (and in MPFR), it is 6. But this is quite arbitrary.

> > In §12.4: I don't understand the paragraph after the note. Don't
> > you mean interval2exact and interval2text?
> 
> It seems correct & reasonably clear to me. But maybe delete 
> > ", and the operation exact2interval shall be the same as text2interval"
> 
> and at the end of that paragraph add
> > Since s is an interval literal whose exact value equals x, the
> > operation T-text2interval will recover x exactly and can be used
> > to perform the function of T-exact2interval.
> 
> Does that say it better?

Perhaps. Now, this has never been discussed. As I've said in some
other mail, you don't need an "exact representation" for recovery.
This may be better, as much less ambiguous than some inexact
representation with specific rules. I don't know.

> > I think 0 should also be represented as "0".
> When? Instead of the hex-sig form "0x0p0"?

Well, actually the implementation should decide. IMHO, if l and u are
integers, it should be OK to represent them as decimal numbers.

Note that decimal output is traditionally used even for non-integers,
but this is not a problem for recovery if enough digits are used for
that.

> > And couldn't interval literals "[x]" be allowed for point intervals?
> For this & the previous: exact representation is meant to be
> human-readable, but that's not its prime aim! A simple description
> is more important. These seem low-priority changes. Unless I'm
> misunderstanding you.

But in such a case, is it important to specify the format?

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)