Re: Revised FlavorsText
Michel
On 2014 Mar 19, at 13:17, Michel Hack wrote:
> Guillaume Melquiond wrote, on comparability of accuracy modes:
>> ... So the implementer decides to introduce the "tight in practice"
>> mode, which it is impossible to order with respect to all the other
>> modes. Indeed, it is worse than "tight", better than "not even
>> accurate", but uncomparable with "accurate".
>
> I had given another example a few months ago, when I tried to talk John
> out of requiring a linear order: a choice of "accurate" libraries, one
> optimized for time and one optimized for space. They have different
> ranges where one gives tighter bounds than the other, so they are not
> comparable. But both are better than "valid" and worse than "tightest".
It seems you *did* talk me out of requiring it. The only reference to ordering of accuracy modes in the current text seems to be 7.5.5 which is only "should":
> To simplify the user interface, modes should be linearly ordered by strength...
I'll tone it down further if you feel strongly, say to
> It is recommended that to simplify the user interface, modes be linearly ordered by strength...
But I still wonder if I've failed to understand some key point that led to Guillaume's criticism.
John Pryce