Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
So beside the argument of unknown origin. Are there practical considerations in favor of one or the other version? Siegfried sent the example code from INTLAB to support intval(1e400) = [realmax, oo]. As this discussion went on for some time, I don't remember if there were practical arguments for the other version (apart from oo is not a real number and therefore no interval can be constructed containing it).If intval(1e400) is interpreted as a proper interval then, for the same reasons, 1e400+xx, 1e400*xx, xx/1e100, etc should also interpret 1e400 as a proper interval. Therefore, specifying the result of mixed (real, interval) operations becomesmore combersome, since phi(inf) and inf circ real must be treated completely differently from the other cases.
I think I'm missing something here. But don't you have to check for the real argument being oo in both cases? Taking 1e400+xx for example: With intval(1e400) interpreted as [realmax,oo], the implementation of real + interval would have to contain something like
if (real == oo) return [realmax,oo] + xx else return real + xx(please excuse the lax notation, I hope the point becomes clear). But with intval(1e400) being interpreted as empty, it would be
if (real == oo) return [NaN, NaN] else return real + xx? Or how do you derive the [NaN, NaN] for an infinite input without special casing?
Cheers, Christian -- /"\ Christian Keil \ / ASCII Ribbon Campaign mail:c.keil@xxxxxxxxxxxxx X against HTML email & vCards / \