Re: A proposal for the next motion
Dear Nate,
On 2009-05-13 20:47:53 -0400, Nate Hayes wrote:
> Dear Vincent,
>
> >Vincent Lefevre wrote:
> > On 2009-05-13 18:23:30 -0400, Nate Hayes wrote:
> >> Global flags are technology from the 70's and don't work well in
> >> modern multi-core, multi-threaded computing environments.
> >
> > Flags are part of the IEEE 754 standard. That's why I mentioned them.
> > And there are no problems with multi-core, multi-threaded
> > environments. This is just a matter of implementation, which can be
> > efficient or not.
>
> I don't agree. Flags can be problematic and source of performance loss in
> massively parallel applications. The problem is exacerbated in SIMD
> processing environments. A propagating NaI is more efficient in these
> scenarios.
>
> IEEE 754-2008 re-words parts of the standard to get away from the global
> flags concept.
There are (global) flags in IEEE 754-2008. Their scope is language-defined.
> >>> This is not acceptable. In particular, what would you do if the
> >>> natural domain of the function is not an interval or is an interval
> >>> having an endpoint that is not an exactly representable number?
> >>
> >> For the mathematical functions likely to be included in a 1788
> >> standard, the natural domain can be represented by machine numbers.
> >
> > The behavior should be general enough to be extended to common
> > functions that would not necessarily be in the 1788 standard.
>
> I don't see why.
Because the user may need other functions. For instance, the C language
defines more functions than IEEE 754. So does LIA. But such functions
can be seen as conforming to IEEE 754; see 9.1:
For one or more formats, language standards and implementations
might define one or more floating-point functions, not otherwise
defined in this document, that conform to this standard by meeting
all the requirements of this subclause.
1788 should have a clause like that too.
> >> If a counter-example really does exist, the two opcode solution
> >> mentioned above would be better idea, I think.
> >
> > It is not difficult to find counter-examples: the division (e.g. 1/x),
> > tan, arcsin...
>
> If "eps" is smallest machine number, then
>
> 1/([0,3]&[eps,+oo)) = 1/[eps,3] = [1/3,+oo)
Your reasoning is incorrect. You cannot transform 1/eps into +oo (this
can work with some arithmetics, but not with all of them)!
Also, 1788 should make the underlying arithmetic transparent. I mean,
the user should not wonder what the smallest machine number is, for
instance.
And the user should not have to reimplement interval arithmetic or
parts of it (like determining special points in an interval, such
as points on which the function is not defined -- that may be quite
difficult, e.g. for tan).
> produces correct result in floating-point. I don't know if trig functions
> will be included in 1788 or not, but the natural domain of all inverse trig
> functions (even the inverse hyperbolic functions) are easily represented
> exactly in floating-point, e.g, the natural domain of arcsin is [-1,1].
Yes, you're right for arcsin, but function tan would still be problematic
(and other possible functions not defined in 1788 but seen as confirming
just like what IEEE 754 allows).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)