Re: A proposal for the next motion
> Date: Tue, 19 May 2009 09:39:44 -0400
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: A proposal for the next motion
> To: STDS-1788@xxxxxxxxxxxxxxxxx
>
> Dear Dan,
>
> I don't argue at all the points you make about Vincent's idea. Clearly they
> are true. Whether it is practical or realistic to expect hardware vendors to
Aye, there's the rub.
This would add some odd number of tag bits to each interval.
Odd as in strange. Even an extra 32 bits would be odd. It
would make an object that is currently a power of two number
of bits into something else.
The tags need not be stored in the same place as the interval
proper but they need to be associated with it in some way.
It makes the hardware task of managing these tags no more
difficult on the hardware guys than managing global state bits
but it makes the task of addressing intervals somewhat more
difficult. (No more than modern architectures can handle but
not as easy as a power of two.)
> support that idea is another question. I can see at the language or
> application level that model may work very well, particularly in CAS like
> Mathematica or something.
Actually I believe the compiler guys will have some difficulty
as well.
Besides the problems mentioned above they would also have to
contend with various possible optimizations. For example it
might be possible to eliminate the tags altogether if the
compiler can determine that the user never looks at them.
The decision would be to trade off the memory saved & addressing
simplified versus hardware that is expecting to see them.
>
> If you and Vincent are serious, why don't you write a paper or proposal.
> That way we can see the details of how it is supposed to work. Especially if
> you could address the concerns I raise in my previous e-mail to Vincent, I
> would take a closer look.
>
> Best,
>
> Nate
>
You misunderstand the situation.
Vincent & I have not communicated in any way on this topic. He
proposed it & I commented on it. You have seen every word I've
had to say on the topic.
And if you have been reading carefully you will note that I'm not
sure this is something we should do. As a former hardware guy
the difficulties flew right into my face.
But as I looked at it I realized that the hardware problems were
not that bad. I am not a compiler expert but I believe the
compiler problems are also managable.
And for this admittedly non-zero price we buy the synthesis of
the modal & c-set approaches. As Baker suggested, we also might
get things like John's 'discontinuous' flag.
Therefore, for the moment, the best I can say is that I support
the exploration & discussion of this idea.
For example, besides the 754 flag bits (extended to intervals in
some way) we could have tags that stand for:
NaI - Some condition which would generate a non-interval
has happened. Perhaps including things like the
possiblyUndefined flag in 3.4 of the Vienna
document.
Empty - The empty set was returned.
Discontinuous - A function was evaluated in a (possibly)
discontinuous portion of its domain. Much like
definedButPossiblyDiscontinuous in Vienna 3.4.
NonStandard - A non-standard interval was created.
Infinite - A interval of infinite width was created.
Inaccurate - An interval was created in an inaccurate
manner. More so than merely inexact. I get
this from 3.2 Accuracy Modes in the Vienna
document.
These are just off the top of my head & from a quick read of the
Vienna document. But look at some of the implications:
Both 'NaI' & 'empty' can be made as persistent &
testable as you want them to be.
We buy the elimination of the c-set versus modal
argument.
'Inaccurate' gives us the ability to use less than
correct rounding so long as we tag it as such. This
might obviate the need for us to specify the accuracy
of transcendental functions. Further, when we use
implicit conversions we can return:
{xx_64bit,Inaccurate} <- {xx_32bit,Inexact}
as an indication that part of the calculation was
carried out in less than the resulting precision.
The same thing could be done on string to interval
conversions.
You are the experts. I suspect there are more & more important
things that might be tracked in this manner.
We might get to the point where we want to limit the things we
track in these tag bits.
I don't know.
But don't you think its worth exploring & discussing?
Dan