Re: Constructors & decorations
Dan Zuras Intervals wrote:
I believe not. I think the intention of Motion 8 is that once
an interval is set notValid, _all_ its other attributes become
meaningless. It has fallen into a black hole. So a V- interval
is essentially the same as NaI. It follows that all query-functions
on it should give results of maximum meaninglessness:
- Its other decorations should be D0 C0 B0.
- Its lower & upper bounds, midpoint, radius etc., should all
return NaN.
So it seems that you are reserving the interpretation
of 'Valid' things to those things which are imported
into intervals from other arithmetics. Constructors,
converters, & the like.
Does that not seem like a particularly narrow use for
a decoration? Would not 'Defined' do as well?
I say this because decoration bits might end up being
expensive things some day. If we are successful &
intervals find their way into hardware, decoration bits
will become state bits. They will have interlocks &
busses devoted to them. They will be saved on context
switch. They will become involved in issues of
parallelism & cache coherency. We should make sure
they are useful.
On the one hand, I will argue that parsimony suggests
that overloading constructor issues into the 'Defined'
decoration might be desired.
I agree this is a very important question for us to consider.
On the other hand, before we are done I suspect we may
need decorations beyond 'Defined', 'Continuous', &
'Bounded'. For example, 'Standard' (versus
non-standard). As well as 'Accurate'. And possibly
'Empty'.
Perhaps. I don't know for sure.
I have a feeling the opposite may be true, i.e., that "Defined,"
"Continuous," and "Bounded" might be all that is required.
I even have some inclinations it may be possible to eliminate the "Bounded"
attribute by considering IEEE infinities as overflows. Ian McIntosh had a
very interesting post a ways back on this topic. I'd like to see it
considered in more detail at some point in the future.
Thanks for raising these issues Dan. I also would like to look
at them in more detail. If the semantics of decorations turn out
to be too complicated to explain to the ordinary user, we need
to re-think.
Regards
John
I think the semantics of decorations can be simplified
to the same 3-state state machine for all decorations
if they are named properly. Only the sense of the name
(the usual thing versus the unusual thing) needs to be
pinned down. Then the state machine will work.
This is the ideal situation for us to shoot for... I wholeheartedly agree!
This will also facilitate fast and efficient implemenations, even in
software. Ideally, all progation rules can be implemented by bitwise AND/OR
operations. This is already the case for "Defined" and "Continuous"
attributes ("Bounded" seems to be the ugly duckling).
But I will save my arguments for a future note.
Motion 11 is on the table today. We should devote our
time to that.
I agree. If there is an offline discussion on these topics, though, I'm
interested to participate.
Nate
Also, the rest of my life has intervened to prevent me
from writing up my thoughts on this matter so I'm not
ready yet. :-)
I'm sure there are many of you who know how that feels.
Until then,
Dan