Baker,
I'm not aware of the IEEE reflector... not sure what you mean. (So, no.)
Currently, my intervals are defined very nearly the same as the 1788 has defined,
except that I treat -oo and +oo as proper numbers... and so, for the most part,
all operations return the same except that I allow [-oo, -oo] and [+oo, +oo] as
valid inputs and valid outputs that the 1788 doesn't allow... so, that's not a conflict,
since such behavior is not defined by 1788.
I think the only conflicts with 1788 are the few cases where 1788 returns Empty
that I might return [+oo, +oo], [-oo, -oo], or [-oo, +oo].
Brian
On May 27, 2011, at 10:49 AM, Ralph Baker Kearfott wrote:
Brian,
Have you posted this to the IEEE reflector? In particular, the IEEE
extended arithmetic can still be used to compute with the
"reals-based" interval arithmetic, but with somewhat
different rules. (I need to review the precise differences.)
Also, how exactly are you using the extended IEEE arithmetic
in YOUR interval computations?
Best regards,
Baker
On 05/27/2011 07:05 AM, Brian Kennedy wrote:
Hi!
I have an engineering application that, in its depths, performs some interval arithmetic in combination with floating point arithmetic. As originally designed, that interval arithmetic was on intervals of IEEE floating point numbers (since that's what it used in non-interval code, what the engineers were used to, and what the hardware supported)... or more precisely, on intervals of extended reals.
I have been considering a shift to intervals of reals instead, in order to align with the emerging interval arithmetic standard, and to benefit from the interval expertise that chose to standardize that approach. As I do that, I am wondering if there's some experience out there that I might benefit from...
Have any of you switched your software from intervals of extended reals to intervals of reals?
And if so:
Are there any particular caveats or issues that you ran into with the code or algorithms that were originally designed for the one and needed to switch to the other?
Did any of you start down that path and then realize that it violated too many assumptions of the dependent code or was too expensive with current hardware, and decided to abort making that change?
Of course, if someone has published a paper on their experiences making that switch, I would love a pointer.
Thanks,
Brian
--
---------------------------------------------------------------
R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------