dependent and independent intervals, proposal to toss out text2interval. Was re: about emp (was: Motion 42:no)
Richard Fateman wrote:
> I think that whatever advantage can be gained by allowing an
> implementation to process string expressions like "0.1 + pi"
> is more than overcome by requiring the library of programs
> double_float_text2interval etc. to include a parser, evaluator
> of arbitrary-precision (or perhaps exact rational) arithmetic,
> an algebraic simplifier, and perhaps more.
The standard does not require this, but it allows it. It makes
it possible for a standard-complying implementation to offer tight
enclosures, which would not be possible if one had to go through
standard non-interval literals, which would most likely suffer
inappropriate rounding (unless one carries the context around,
as in my macro example below).
The compiler would do the same amount of work for text2interval("1")
(via constant propagation) as for nums2interval(1.0, 1.0), but it would
get text2interval("0.1") right. Note that text2interval() could be
coded as a bunch of C macros (assuming block-scope rounding):
#define lower(s) { fesetround(FE_DOWNWARD); atof(s); }
#define upper(s) { fesetround(FE_UPWARD); atof(s); }
#define test2interval(s) nums2interval(lower(s),upper(s))
So, at the very least text2interval() would recognize the same strings
as atof() -- but it could (being a new function) support more, such as
named constants (of which it already supports a few, like Inf) like Pi.
In languages with first-class interval support it could of course do
even better, by allowing any constant expression already supported in
other contexts, such as initializers. But I would not expect this in
a second-class (i.e. macro-and-library-based) implementation.
>On 2/19/2013 2:00 AM, Guillaume Melquiond wrote:
>...
>> I test whether the two arguments point to the same memory location,
>> and if they do, I compute the square instead of the product. Seems
>> clever and foolproof, right? Wrong. If any of the following happens,
>> the answer will be incorrect:
>> ...
> This is all entirely correct. There is a way around problems(1-4) which
> is to add a sequential marker to each newly-generated-interval-datum.
This is basically what I said earlier: (Tue, 19 Feb 2013 11:12:54 -0500)
| So, do we want to introduce an explicit tagging mechanism? (This would
| immediately "solve" the 17-byte problem!)
Michel.
P.S. Some compilers support flags to control the rounding applied to
literals, but I'm not sure there exist pragmas to support this
on the much finer level of individual expressions.)
---Sent: 2013-02-19 23:08:58 UTC