Infinity is needed, not just as a lower
or upper bound, but as a value. Lots of reasons:
I consider this as a special case of
"Thou shalt not lie." Treating an answer that should be
+/-Infinity as not having an answer (empty) is a form of lieing.
For I3 = op (I1, I2), it should be true
that if x is in I1 and y is in I2, that x op y is in I3. Saying I3
is Empty means you aren't answering the question. Doing that when
it's not necessary to is undesirable. Empty has its own meaning and
uses, and we shouldn't mash empty and infinity together.
It's important for a standard to be
inclusive, and not exclude valid applications unnecessarily. There
will be many applications of IA beyond what is being done now.
One obvious example of a useful application
would be to transform a non-IA program into an IA one, to do error analysis.
A very simple example might be feeding millions of values into a
math library sqrt implementation (perhaps one that does multiple square
roots in parallel). The specification includes that sqrt (+Infinity)
is +Infinity, and sqrt (any quiet NaN) = the same quiet NaN. If IA
doesn't allow working with those values what do you do? Do those
ones by hand? Use some non-1788 IA system? And if you produce
[Empty], how do you distinguish values that should be infinity from those
that should be NaNs?
Any standard will be more successful
if it allows more uses. Some of the IA uses will naturally produce
or need to consume infinities. We shouldn't rule all those out now,
before we can even imagine them. A couple of less obvious places
IA could be useful:
- Project planning: Using
IA ranges, calculate for example task_time = 1 to 2.5
pw + 4.2 to 6 pw = 5.2 to 8.5 pw, then that
calendar_time = task_time / workers.
What if workers = 0? An
infinite calendar time is more meaningful and useful than an empty time.
Which bar on a graph shows management where to add people - a tall
bar with "oo" at the top, or an empty bar?
- Financial analysis: Using
IA ranges for many possible investment situations, calculate return_on_investment
= profit / cost, then sort them by value.
What if cost = 0? An
infinite ROI is a lot better than an empty one. Which one tells you
more - "Take this freebie!" or "Sorry, I couldn't calculate
your results on this one."?
The point isn't that these applications
should necessarily be implemented using 1788 IA (but why shouldn't they?).
It's that once something is available, people will use it in ways
we can't anticipate, and for IA some (many?) of those uses will need infinities.
Even checking "Is the bridge safe?" can involve infinity
if the net support at some point is zero. The engineers need to know
that, not that after all that work they don't have an answer. Having
the 1788 standard force appllications to use some non-1788 system to get
useful results isn't beneficial to anybody.
The argument against including Infinities
seems circular to me. If you decide that IA is based on R, then you
have to produce [Empty] for expressions where the natural result is +/-Infinity.
You have to simply because you don't allow [+/-Infinity]. But
if you instead base IA on R*, then you can produce [+/-Infinity]. The
set is still closed (yes, I'm assuming NaI will exist). It's better
because it defines an informative result value for operations for which
you would otherwise say there is no result.
If you have a application that could
produce an infinity it's more useful to get infinity than an ambiguous
empty set that could have been produced for other reasons. If you
have a series of operations that produce infinity and you don't like Infinity,
it's easy to just treat it as Empty. If you produced Empty instead,
it's unsafe to treat that as Infinity when it could have been produced
from other operations like an empty intersection. For at least some
applications, you'd want to keep separate variables saying whether to treat
each particular Empty as really Empty or as Infinity. Some could
simply test the result of every divide etc. and if it poduced Empty when
its inputs ween't then convert it to Infinity. Oh, wait, 1788 doesn't
allow Infinity. Hmmm. Maybe convert the value to [MaxFinite,
Infinity], but that's awkward and a fib. OK, let's use some non-1788
system so we can get the job done right.
IA needs to coexist with regular 754
floating point. That means they should have the same base, instead
of IA being a subset. You don't need as many guardian dragons or
dogs if you don't have as many dangers to guard against.
IA will likely be implemented using
754, and the extra checks to ensure operations don't produce infinity will
make the programs bigger and slower, for negative benefit.
I know Wikipedia has flaws, but its
IA write-up assumes IA is based on R* and includes infinities. Somebody
uses them, and believes they're using a consistent system.
The bottom line for me is that to reject
infinities is to cripple ourselves, to deliberately shoot ouselves in both
feet, and I'm not a masochist. Let's start with R* and Infinity instead
of without them.
If you voted Yes and are no uncertain,
remember that you can change your vote.
Voting against Motion 3 doesn't imply
that you've approved allowing infinity, it just keeps the option open for
more consideration. It isn't my preference, but a dual standard allowing
operations with / without infinity (eg, by having two forms of divide,
or two forms of Interval) is infinitely better than prohibiting it.
- Ian McIntosh, donning my asbestos
suit 8<) Toronto IBM Lab
8200 Warden D2-445
"R. Baker Kearfott"
<rbk@xxxxxxxxxxxxx>
06/04/2009 10:47 AM
Please respond to
"R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>
To
Ian McIntosh/Toronto/IBM@IBMCA
cc
Subject
Discussion period for Motion 3 ends
"today"
IEEE P-1788 members:
The discussion period for motion 3 officially ends today.
So far, I have seen no formal motions to amend, with seconds.
(Such motions would begin "I move that we amend ... by ...".)
Absent further discussion, official voting will begin on Tuesday,
April 7, 2009. For official purposes, Tuesday April 7 means when
it is Tuesday, April 7 at distance \epsilon east of the international
date line, for arbitrarily small \epsilon.
Best regards,
Baker
--
---------------------------------------------------------------
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
---------------------------------------------------------------