Re: A proposal for the next motion
I don't have any problem discussing these ideas. Admittedly, I have my
reservations it is the right option for 1788, but that doesn't mean we won't
learn anything valuable.
Of course, I speak only for myself.
Others may or may not feel the same way... the "evil eye," remember... ;-)
Nate
----- Original Message -----
From: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
Cc: <STDS-1788@xxxxxxxxxxxxxxxxx>; "Dan Zuras Intervals"
<intervals08@xxxxxxxxxxxxxx>
Sent: Tuesday, May 19, 2009 10:55 AM
Subject: 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