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

Re: text2interval again

On 03/07/2013 02:03 AM, Richard Fateman wrote:

I am curious about your note because I agree with your final paragraph, but
dosagree with much of the earlier material!


On 3/6/2013 10:16 AM, Michel Hack wrote:

Richard Fateman wrote:

If you can serialize numbers, you can serialize intervals.
(arguably therefore you don't need text2interval)

On the contrary -- it means that you don't need nums2interval()!

Hardly the case, since nums2interval() would be need whenever the endpoints
are computed  as scalars rather than read in as literal constants.
This would not be enough as the error in a computed scalar can be arbitrarily large, depending on how it was computed. It would be enough only if it were known that the computation was just an optimally rounded conversion. But in this case it is better to do the two steps at once with a single call to text2interval (which even gives more accurate results in case the conversion was exact).
Your recipe also loses accuracy when the first rounding was without error. For example when processing 1.0 with your procedure it would produce [0.9999999999999,1.000000000001] rather than the wanted result [1.0000000000000,1.0000000000000] produced by text2interval. In addition to producing an inferior result, it is more complicated to write in a program and is error prone (as an inexperienced user may forget the second step). 



As mentioned many times already, interval bounds have to be derived
using appropriate rounding directions, so when a literal is used to
derive an interval endpoint, the literal has to be interpreted in
the appropriate context.

OK, I think this is where I disagree.  The result of OPERATIONS like +
and *
require attention to rounding directions.  When a literal is used to
initialize
a value, and that value is used as an endpoint, why not use that value?
The value is determined by the mathematical problem posed, which is usually in text format. An improperly rounded conversion changes the mathematical problem.
If we want to prove the theorem that x in [0.1,0.2] implies f(x) in [result], we need to be sure that the computer does not prove 
    x in [0.10000000000001,0.199999999999999] implies
                                              f(x) in [approx_result]
(which is useless as it might be that f(0.1) \not in [approx_result]).
Instead we want it to prove
    x in [0.0,9999999999999,0.2]0000000000001 implies
                                            f(x) in [enclosed_result]
which guarantees x in [0.1,0.2] implies f(x) in [enclosed_result]
This is the main reason why an outward rounding text2interval routine is needed. 




  This context is lost if the literal is
first converted to a number, and then used later to construct an
interval.

The context for the literal is "This number has previousl been computed or
  read in by the normal input routine
for the programming language".  It ceases to have meaning as 0.1 or 0.3
and now
only has meaning  3FB999999999999A  or 3FD3333333333333 and is devoid of
history or rounding mode.
Precisely this is the problem. The semantics changes when going from text to float, and this must be avoided if we want to solve a problem which is defined by the semantics of the underlying text.
text2interval ensures that the floating-point computations in an interval context will not change the meaning of the originally posed problem in spite of the change in semantics for the underlying floating point processing. 


Arnold Neumaier