Re: Vectorizing motion 8
Note : "vectorizing" is an inadequate subject summary for my remarks.
I only mentioned this aspect because my counter proposal does support
it as well. "variant functions vs variant types" seems a better
description to me.
Nate Hayes a écrit :
Sylvain Pion wrote:
My goal here is to make it *easy* for hardware vendors
to support the critical interval operations. That is,
it should be a relative no-brainer to extend an existing
SIMD unit to support the interval functions of this standard.
Concretely, what I would propose instead would be to have
functions like sqrt(x) which return an interval y, together
with the "exceptional" information in a separate (integer) register i.
This should vectorize without problem, with an accompanying
integer vector-register.
Then if you need to propagate or combine the information
one way or another, you do it by considering the information
registers.
I also agree with all of this, although IMHO what you describe is a
concrete implementation of a decorated interval. So it is an example of
a (would-be) conforming implementation.
For example, if the values in the integer registers are not propogated,
then this can be viewed as a "forgetful" operation.
Yes.
I am objecting to the presentation that this motion promotes.
You designed it by taking a higher abstraction level, I understand that.
But, fundamentally, this motion says nothing since we don't even
know what exceptional property we need ! I would have prefered
to see this important debate (which properties) take place before
this one, otherwise I fear that we will speculate too much and
run the risk of divergence.
This is just not the right order to do things for me. We should
agree on the functionality first, and the presentation details next.
But anyway, I do not like this presentation of the future functionality.
Of course, at the programming language level, one can
encapsulate all the propagation rules the way the motion says
(or rather, says a later motion would specify).
But I think that this part should not be specified in this standard.
I agree.
This was by design.
And it is surely fine if you have in mind the design of a C++ class
interface for example. That said, even in this case, instead of only
2 types, you could think of a policy-based design for specifying which
property you want to propagate (more type combinations than just
bare and decorated). So, to me, all this discussion belongs to a
much higher level than what we should be doing for this standard.
Basically, I guess my main objection about this way of presenting the
exceptional properties is that this motion introduces more types of
intervals, hence more complexity. This has the potential to lead to
a combinatorial explosion when you add "non-standard" intervals of any
kind into the picture. Moreover, I fear that it will most probably make
it harder for us to decide later on a memory representation of (decorated)
intervals.
I would rather, instead, add more variants of functions. This is what
will map better to the hardware anyway, and seems more in line to an
IEEE-754-like standard (we are under some "microprocessor" hierarchy
of IEEE, IIRC, so we should focus on the memory representation and
the functionality we want).
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/