Re: An error-catching question
Ian McIntosh wrote:
IM> ... All "values" including non-values like NaI need to be represented
somehow in undecorated intervals. ...
NH> This already exists. Motion 8 calls it a "bare decoration".
Actually I didn't mean a bare decoration. I meant an undecorated interval
- an inf-sup pair whose bit pattern means NaI without having a decoration.
Ok. I think there might be a slight misconception:
As Jurgen points out, a Level 3 representation of a bare decoration (NaI)
could be [-NaN,-NaN]. I assume that the decoration bits are stored in the
payload of the NaNs. A branch-and-bound algorithm, for example, needs to
know what exception caused the NaI. If there are no decoration bits
associated with the NaI, then the algorithm won't know what to do (or will
have to make conservative assumptions that could lead to huge amounts of
wasted computational effort). So it is important that decoration bits always
follow the NaI, hence the concept of a "bare decoration."
If the user is really unsure of what the decorations of the NaI should be
when performing an explicit construction of a bare decoration, then all
decorations can be initialized to thier worst state. e.g., the "domain"
tetrit can be initialized to (F,F) and the "defined and continuous" bit
can be set to F.
In this way, the NaI will then be "Uber NaI", in the sense it will clobber
absolutely everything it comes in contact with and guarantee to propagate
through any lengthy computation without being "absorbed" or unitentionally
lost. This would be a really appropirate way for a compiler to represent
uninitialized variables, for example.
NH> ... some will ... then propagate only a bare decoration (NaI).
Yes, it may be uncommon to construct a bare decoration from non-interval
values, but there should be a constructor for that too.
Right. I think so (see above).
In both cases you can construct a decorated interval then throw away the
part you don't need. If they have to people will write their own
constructor wrappers to do that, but it's easier and safer for the system
to provide those. This might be considered a language binding issue.
Right.
My important point isn't really whether the standard defines those or not
(language bindings should though). It's that there needs to be an
undecorated interval representation of NaI, whether it comes directly from
an undecorated interval constructor constructing the NaI or by discarding
the decoration of a decorated interval representing a NaI.
I think this could be harmful. In my assesment, it would be better if NaI
always carried the decoration bits, i.e., a "bare decoration" in the Motion
8 sense. As mentioned above, a user that might be unsure how to initialized
the decoration bits can always play it safe by setting them all to the worst
possible state and thereby creating an "Uber NaI" that will always clobber
everything it comes in contact with.
In floating point terms, who would want a system to turn NaNs into some
other value like 0 or -1?
Probably no one. I don't suggest "bare decorations" would allow this,
either.
Who would want a system to turn NaI into some other value?
I hope no one wants this. I sure don't.
Who would want a standard to require that?
Not me!
Please keep in mind that Clause 2.3 of Motion 8 specifically requires that
any arithmetic operation on bare decorations must return a bare decoration.
This is consistent with the "Uber NaI" concept mentioned above. In other
words, once a forgetful operator is used to strip away the interval portion
of a decorated interval, no arithmetic operation will ever be allowed to
propagate anything other than a bare decoration for such an operand. This is
consistent with how IEEE 754 propagates NaNs in floating-point computations
and, I believe, addresses the conerns you've raised.
Nate
- Ian McIntosh IBM Canada Lab Compiler Back End Support
and Development
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Ian McIntosh/Toronto/IBM@IBMCA
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|09/10/2010 11:23 AM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: An error-catching question
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Iam Mcintosh wrote:
There's no point having undecorated intervals unless users can get
correct
answers with them. The purpose of decorations is to add more information
about why value is what it is. All "values" including non-values like NaI
need to be represented somehow in undecorated intervals. So there has to
be an undecorated representation for Not An Interval, and a constructor
that can produce it.
Ian,
This already exists. Motion 8 calls it a "bare decoration".
I believe this is what Arnold was referring to, i.e., once a decorated
interval is constructed, either the interval portion can be thrown away
leaving only a bare decoration (NaI), or else the decoration portion can be
thrown away leaving only a bare interval (empty set).
Obviously there also needs to be a decorated interval constructor able to
produce a decorated Not An Interval. Some will use decorated intervals
exclusively so will use that. Others will use undecorated intervals
exclusively and miss out on some features they don't need (or don't think
they need) but gain performance.
Don't forget the third option:
some will use bare (undecorated) intervals until an exception occurs, and
then propagate only a bare decoration (NaI).
This is typically the case in branch-and-bound interval algorithms, for
example, where using decorated intervals for all computations is a huge
waste: as long as no exception occurs, then bare intervals are all the
algorithm needs. As soon as an exception occurs, however, the algorithm no
longer needs any bare interval and only requires a bare decoration (NaI) to
progpagate through the rest of the computation.
Some will mix the two, either carefully
or carelessly. Each will use what they think is best for their specific
application, and a standards committee needs to consider all their needs.
This is especially important to anyone who even dreams of replacing any
current or future 754 usage.
Agreed!
Nate
- Ian McIntosh IBM Canada Lab Compiler Back End Support
and Development
|------------>
| From: |
|------------>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
|
--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|Ian McIntosh/Toronto/IBM@IBMCA
|
--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|09/10/2010 06:01 AM
|
--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: An error-catching question
|
--------------------------------------------------------------------------------------------------------------------------------------------------|
John Pryce wrote:
P1788
This doesn't mean I'm trying to catch you out. But, as I'm finalising a
revision of a motion on the "defined and continuous" (actually, its
negation) decoration bit I see a problem as follows.
Nate Hayes has pointed out that good practice with decorated intervals
("dintervals") is: Use them sparingly. E.g. if you have one function f
whose continuity must be checked, use dintervals inside the code of f, but
bare intervals elsewhere.
But, at present our only way to flag a wrong constructor call like
"interval from 3 to NaN" is by setting a decoration (a value of the domain
tetrit, in Hayes' scheme; or set the "illformed" bit, in mine). An interval
thus decorated is to behave exactly like "NaI".
A constructor for a bare interval can't do that. Briefly put
Dinterval(3,NaN) can make a result that behaves like NaI.
Interval(3,NaN) can't. So what _should_ it return?
I can see various possibilities, none very satisfactory. Your solutions,
please.
I think that a constructor should always produce a decorated interval,
and the programmer cvan then decide to throw away the decoration,
if desired (after querying the result, if needed).
Arnold Neumaier