Code with apache-2 on /usr/src

[Adhemerval Zanella]

On 28/05/2018 18:09, Steve Kargl wrote:
> 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.
> 

Also keep in mind my initial idea is to propose patches only to expf, powf, 
logf, expf2, and log2f.