Elementary Function Work

[N.G. Timmons]

Hi,

Apologies, I should have been more clear in my original e-mail.

>> I was looking through the source for sin/cos/exp etc. and noticed that 
>> a
>> lot of the comments don't actually say what/why things are being done.

For this I was referring to the 32-bit float implementations, but in 
general I was thinking about describing the algorithm being used so that 
people can understand if they need to check the source for any reason.

I really like the idea of new implementations for double or float that 
would improve performance - if I could help with that I would be very 
grateful.

>> There also exists a union type called "mynumber" which is used to 
>> access
>> the high and low bits of a 64-bit floating point number.

For this one I was initially interested in renaming it to something 
meaningful because when I first looked through the code I was really 
confused when I first saw it and navigating the source (especially 
online) can be a bit tricky to find the definition.

> Typically testing information (beyond the glibc testsuite) would go in 
> the
> commit message for a change, describing how that change was tested, not 
> in
> the source code.  Comments need to be kept up to date to reflect the
> version of the source code they appear in, saying "tested with the 
> glibc
> testsuite" is redundant while describing some other tests that were run
> either (a) imposes a load on everyone modifying that code in future to
> rerun exactly those tests, (b) leaves information in the source code 
> that
> becomes out of date as soon as changes are made, or (c) has to be 
> removed
> when changes are made as it may not describe how that changed version 
> was
> tested.

This makes sense.
I would be interested in setting up a test suite to provide ULP error 
information, error distribution information and number of known 
incorrectly rounded results that could be run to generate a 
documentation page or automatically update the function comment with the 
information for easy accessibility.
This is of particular interest to me as I am studying for my PhD in 
approximate computation and have found that different libm 
implementations have different error distributions and mismatch counts 
which affects interoperability. Part of my research output would be 
raising awareness of this. So if this information would be valuable to 
this project, it would be great to be able to implement this helper 
tool.

Thanks
Nick



On 2020-12-07 19:19, Joseph Myers wrote:
> On Mon, 7 Dec 2020, N.G. Timmons via Libc-alpha wrote:
> 
>> I was looking through the source for sin/cos/exp etc. and noticed that 
>> a
>> lot of the comments don't actually say what/why things are being done.
> 
> exp is now one of the optimized Arm implementations, which have 
> detailed
> comments.
> 
> sin and cos for double are from the much older IBM libm.  It's quite
> possible they could be replaced by new implementations along the lines 
> of
> those for float and be made significantly faster in the process.
> 
>> There also exists a union type called "mynumber" which is used to 
>> access
>> the high and low bits of a 64-bit floating point number.
> 
> Where this is used to initialize tables of floating-point values using
> specific representations, with #ifdef cases for the endianness, it 
> would
> be better to replace uses by uses of double, with hex float constants
> (verifying that installed stripped shared libraries are unchanged in 
> the
> process).
> 
>>      - Actual testing information (the current statistics given at the
>> top of some functions doesn't say how they were tested). This is to
>> allow for verification and comparison if future changes are made.
> 
> Typically testing information (beyond the glibc testsuite) would go in 
> the
> commit message for a change, describing how that change was tested, not 
> in
> the source code.  Comments need to be kept up to date to reflect the
> version of the source code they appear in, saying "tested with the 
> glibc
> testsuite" is redundant while describing some other tests that were run
> either (a) imposes a load on everyone modifying that code in future to
> rerun exactly those tests, (b) leaves information in the source code 
> that
> becomes out of date as soon as changes are made, or (c) has to be 
> removed
> when changes are made as it may not describe how that changed version 
> was
> tested.