Code with apache-2 on /usr/src
Steve Kargl
sgk at troutmask.apl.washington.edu
Mon May 28 21:09:09 UTC 2018
On Mon, May 28, 2018 at 05:47:09PM -0300, Adhemerval Zanella wrote:
>
> On 28/05/2018 17:21, Steve Kargl wrote:
> > On Mon, May 28, 2018 at 04:47:21PM -0300, Adhemerval Zanella wrote:
> >>
> >> On 28/05/2018 16:35, Steve Kargl wrote:
> >>>
> >>> The above URL seems to contain only single precision code,
> >>> e.g., sinf(x). What benefit does this code have over the
> >>> current implementations of these functions? Doesn't ARM
> >>> support at least a double precision type?
> >>
> >> Yes, the github repository only contains single precision implementation and
> >> at the moment my idea is to contribute with expf, powf, logf, expf2, and
> >> log2f. All these implementation are faster than current FreeBSD ones (I
> >> plan to dig into with more details in patch proposal).
> >>
> >>> Why have an
> >>> algorithms for single precision that differ from the
> >>> algorithms at higher precision?
> >>>
> >>
> >> Are you asking why use an implementation for single precision and another
> >> for double and/or long double (if the case) or why to use a different
> >> mathematical method for each one?
> >
> > Your question don't make any sense to me. My question means that
> > if you only have ARM-specific single precision routines, then the
> > underlying algorithms for those SP routines will by definition be
> > different than the double and long double precision routines. One
> > can do for example 'diff -u s_sinf.c s_sin.c' while debugging.
> > The difference that one sees are usually restricted to different
> > numerical literal constants and the number of terms in polynomial
> > approximations.
> >
>
> Sorry if I was not clear, I did not fully get your question. Also for avoid
> further misconceptions, this new implementation is *not* ARM-specific, but
> rather a different one which is faster than current for FreeBSD (in fact
> faster on x86 as well).
>
> And is having a different algorithm for single and double prevision
> a blocker for a future patch proposal?
No. Given the comment in sinf.c that max ULP is 0.56072, I do note that
the current implementation of sinf in lib/msun is more accurate (for
interesting values of x). I also looked at single/s_sincosf.c. It is
rather dubious to have 80+ digit numerical constants for a float, which
at most has 9 relevant digits.
--
Steve
More information about the freebsd-hackers
mailing list