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

Re: Difficulties in implementation of textToInterval(s)



John,

I tried for some time to promote a principle that it is better
to have one standard than two.
The 1788.1 could be a flavor of 1788, but it is a separate standard.

We spent much time during 1788 development to formulate a notion of flavor and common requirements.
We expected that these common requirements are general enough.
Now we are discussing a new standard and it happens that common requirements are too restrictive for 1788.1 .
I feel that something is wrong - either flavor notion of 1788 or extra resistance of 1788.1 .

However, I don't hope to convince the group.
I stop my discussion though I will personally vote NO.

Best Regards,
 -Dima


----- Original Message -----
From: PryceJD1@xxxxxxxxxxxxx
To: dmitry.nadezhin@xxxxxxxxxx
Cc: stds-1788@xxxxxxxxxxxxxxxxx
Sent: Tuesday, May 24, 2016 9:54:04 AM GMT +03:00 Iraq
Subject: Re: Difficulties in implementation of textToInterval(s)

P1788.1 members

> On 24 May 2016, at 05:02, Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx> wrote:
> Michel,
> 
>> That's an issue for full 1788 (where we have rational literals).  It does
>> not arise in 1788.1 where all implementations use (or appear to use) b64
>> endpoints.
> 
> I should be more clear. I consider interchanging between 1788 and 1788.1 .
> A program in 1788 computes and outputs result for further processing by
> other programs without knowledge which interval datatypes are native for other program.
> The first program doesn't want to loose precision in conversions.
> So it outputs interval literals by s=intervalToExact(x).
> If datatype of the first program contains intervals with rational ends,
> it will outputs interval literals with rational number literals.
> 
> Some of the second programs are in 1788.1 .
> They should be able to read the output of the first program containing rational number literals. 
Apart from the technical issues there's a point of principle. Should a simplified version of a standard be able to *read* (even if it can't write) external, i.e. text, forms of objects written by the full standard? It's not obvious to me that the pros of this outweigh the cons, and it's up to Dima to convince us. 

If we accept it now it might be a burden in the future. E.g. suppose the next revision decides P1788 shall be able to *read & write* interval endpoints in a continued fraction syntax, does that impose an obligation on P1788.1 to *read* them in that form?

John Pryce