The method double.LogP1 seems to have been in .NET since version 7 (from 2022). However, its implementation is useless.
For example, if you attempt double.LogP1(1.23E-15), the expected result is 1.2299999999999993E-15 (for example from the Mercator series; I am taking into account which double representable value is closest to "1.23E-15", and taking into account which representable value is closest to the mathematically precise result based on that). But the actual result is 1.3322676295501871E-15 which is horribly inaccurate.
And if you attempt double.LogP1(1.23E-20), you expect to get 1.23E-20 back. But in the current implementation, you get 0.0. All precision is lost.
If you read the implementation, it is obvious that LogP1 is not really implemented. We just do x+1 which leads to catastrophic loss of precision when x is close to zero. (In fact, Copilot based on Claude-something also sees this immediately if you ask it about that code line.)
Having double.LogP1 gives people the reasonable expectation that we actually provide an implementation that gives the best possible answer, within the precision of System.Double. This is something floating-point libraries typically do offer. It would be much better not to have LogP1, then people would know they would need to write it themselves if they needed any reasonable implementation of f(x) = log(1 + x) for x near zero.
The method
double.LogP1seems to have been in .NET since version 7 (from 2022). However, its implementation is useless.For example, if you attempt
double.LogP1(1.23E-15), the expected result is1.2299999999999993E-15(for example from the Mercator series; I am taking into account whichdoublerepresentable value is closest to "1.23E-15", and taking into account which representable value is closest to the mathematically precise result based on that). But the actual result is1.3322676295501871E-15which is horribly inaccurate.And if you attempt
double.LogP1(1.23E-20), you expect to get1.23E-20back. But in the current implementation, you get0.0. All precision is lost.If you read the implementation, it is obvious that
LogP1is not really implemented. We just dox+1which leads to catastrophic loss of precision whenxis close to zero. (In fact, Copilot based on Claude-something also sees this immediately if you ask it about that code line.)Having
double.LogP1gives people the reasonable expectation that we actually provide an implementation that gives the best possible answer, within the precision ofSystem.Double. This is something floating-point libraries typically do offer. It would be much better not to haveLogP1, then people would know they would need to write it themselves if they needed any reasonable implementation of f(x) = log(1 + x) for x near zero.