On Thursday, 4 June 2020 at 17:41:06 UTC, H. S. Teoh wrote:
>> We are mostly just waiting for the *overloads* to finally make it
>> upstream (e.g., blocked https://github.com/dlang/phobos/pull/7463), so
>> that we can finally enable the commented-out LLVM intrinsics (e.g.,
>> https://github.com/ldc-developers/phobos/blob/26fac3b399c62ead78bedce7ccba9290a2cbbbf3/std/math.d#L4304-L4307).
> [...]
>
> What's blocking the Phobos PR?  Actual issues, or just inertia like much of the Phobos PR queue?

The reason is one click away, in the PR description. ;) - A 3rd-party project tested by BuildKite needs a new release (already adapted).

On Thu, Jun 04, 2020 at 05:45:01PM +0000, kinke via Digitalmars-d wrote:
> On Thursday, 4 June 2020 at 17:41:06 UTC, H. S. Teoh wrote:
> > > We are mostly just waiting for the *overloads* to finally make it
> > > upstream (e.g., blocked https://github.com/dlang/phobos/pull/7463),
> > > so
> > > that we can finally enable the commented-out LLVM intrinsics (e.g.,
> > > https://github.com/ldc-developers/phobos/blob/26fac3b399c62ead78bedce7ccba9290a2cbbbf3/std/math.d#L4304-L4307).
> > [...]
> > 
> > What's blocking the Phobos PR?  Actual issues, or just inertia like much of the Phobos PR queue?
> 
> The reason is one click away, in the PR description. ;) - A 3rd-party
> project tested by BuildKite needs a new release (already adapted).
[...]

So that means this is landing as soon as the 3rd party new release is out?  Finally?


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond

On 6/4/2020 7:40 AM, Timon Gehr wrote:
> In one of my projects I had to manually re-implement all functions that currently forward to libc, because libc is not portable.

How about adding these as PRs to Phobos?

On 05.06.20 05:37, Walter Bright wrote:
> On 6/4/2020 7:40 AM, Timon Gehr wrote:
>> In one of my projects I had to manually re-implement all functions that currently forward to libc, because libc is not portable.
> 
> How about adding these as PRs to Phobos?

Their main feature is portability and I hacked them together quickly. They are unlikely to beat any given libc on other metrics. (e.g., sin and cos are based on cubic interpolation of large lookup tables, good enough to get somewhat close to full float precision.)

Ideally, the standard math functions in Phobos would be portable _because they give correct results_, like the basic arithmetic operators and the square root function in C99.

This seems promising, but I'm not sure what it's current state is: https://hal-ens-lyon.archives-ouvertes.fr/ensl-01529804/file/crlibm.pdf

Also, it's GPL, so we can't port it to Phobos directly:
https://gforge.inria.fr/scm/browser.php?group_id=5929&extra=crlibm

On 6/4/20 10:39 AM, jmh530 wrote:
> On Thursday, 4 June 2020 at 14:14:22 UTC, Andrei Alexandrescu wrote:
>> D should just use the C functions when they offer better speed.
>>
>> https://www.reddit.com/r/programming/comments/gvuy59/a_look_at_chapel_d_and_julia_using_kernel_matrix/fsr4w5o/ 
>>
> 
> Below is a typical example of a std.math implementation for a trig function. It casts everything to real to improve accuracy. This doesn't explain everything, but it's a general strategy in std.math to prefer accuracy over speed.
> 
> real cosh(real x) @safe pure nothrow @nogc
> {
>      //  cosh = (exp(x)+exp(-x))/2.
>      // The naive implementation works correctly.
>      const real y = exp(x);
>      return (y + 1.0/y) * 0.5;
> }
> 
> /// ditto
> double cosh(double x) @safe pure nothrow @nogc { return cosh(cast(real) x); }
> 
> /// ditto
> float cosh(float x) @safe pure nothrow @nogc  { return cosh(cast(real) x); }

This needs to change. It's one thing to offer more precision to the user who consciously uses 80-bit reals, and it's an entirely different thing to force that bias on the user who's okay with double precision.

On 6/4/20 10:40 AM, Timon Gehr wrote:
> On 04.06.20 16:14, Andrei Alexandrescu wrote:
>> D should just use the C functions when they offer better speed.
>>
>> https://www.reddit.com/r/programming/comments/gvuy59/a_look_at_chapel_d_and_julia_using_kernel_matrix/fsr4w5o/ 
>>
> 
> In one of my projects I had to manually re-implement all functions that currently forward to libc, because libc is not portable.

It's totally fine to version() things appropriately. In fact it's the best way - you get to version() in specific libc implementations known to be adequate.

On 6/4/20 10:43 AM, Timon Gehr wrote:
> On 04.06.20 16:40, Timon Gehr wrote:
>> On 04.06.20 16:14, Andrei Alexandrescu wrote:
>>> D should just use the C functions when they offer better speed.
>>>
>>> https://www.reddit.com/r/programming/comments/gvuy59/a_look_at_chapel_d_and_julia_using_kernel_matrix/fsr4w5o/ 
>>>
>>
>> In one of my projects I had to manually re-implement all functions that currently forward to libc, because libc is not portable.
> 
> (Note that this also means if you need portability you have to fork all your dependencies that use Phobos math functions.)

I think it means make Phobos be portable transparently.

On 6/4/20 1:16 PM, kinke wrote:
> On Thursday, 4 June 2020 at 17:04:54 UTC, H. S. Teoh wrote:
>> Would LDC consider providing float/double overloads for std.math functions?  Ideally this would be merged upstream, but sometimes if there's no other way to get things done...
> 
> We are mostly just waiting for the *overloads* to finally make it upstream (e.g., blocked https://github.com/dlang/phobos/pull/7463), so that we can finally enable the commented-out LLVM intrinsics (e.g., https://github.com/ldc-developers/phobos/blob/26fac3b399c62ead78bedce7ccba9290a2cbbbf3/std/math.d#L4304-L4307). - Enabling them already would lead to a different Phobos API for LDC (e.g., log(0.1f) returning a float, not a real), that's why we've been waiting (for years).
> 
> Once the overloads are there (even by just casting and forwarding to the `real`-implementation for now), the remaining transcendental functions can be ported from e.g. Cephes as 2nd step, to have proper implementations for all floating-point types.

Excellent, I see Walter has approved these yesterday. What's the next step?

On Fri, Jun 05, 2020 at 03:39:26PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/4/20 10:39 AM, jmh530 wrote:
[...]
> > Below is a typical example of a std.math implementation for a trig function. It casts everything to real to improve accuracy. This doesn't explain everything, but it's a general strategy in std.math to prefer accuracy over speed.
> > 
> > real cosh(real x) @safe pure nothrow @nogc
> > {
[...]
> > }
> > 
> > /// ditto
> > double cosh(double x) @safe pure nothrow @nogc { return cosh(cast(real)
> > x); }
> > 
> > /// ditto
> > float cosh(float x) @safe pure nothrow @nogc  { return cosh(cast(real)
> > x); }
> 
> This needs to change. It's one thing to offer more precision to the user who consciously uses 80-bit reals, and it's an entirely different thing to force that bias on the user who's okay with double precision.

+100!  std.math has been pessimal for all these years for no good reason, let's get this fixed by making sure this gets pushed through:

	https://github.com/dlang/phobos/pull/7463

AIUI, it's currently only held up by a single 3rd party package awaiting a new release. Once that's done, we need to rectify this pessimal state of affairs.


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.

On Friday, 5 June 2020 at 19:39:26 UTC, Andrei Alexandrescu wrote:
> [snip]
>
> This needs to change. It's one thing to offer more precision to the user who consciously uses 80-bit reals, and it's an entirely different thing to force that bias on the user who's okay with double precision.

I agree with you that more precision should be opt-in.

However, I have always been sympathetic to Walter's argument in favor doing intermediates at the highest precision. There are many good reasons why critical calculations need to be done at the highest precision possible.

In addition, the current PR to remove this behavior will make opt-ing in more difficult. Users will need to either put their own casts everwhere, or basically re-implement what is currently in std.math. It may be a good idea to release std.math in its current state as a separate module, similar to stdx.allocator, (the real versions can just call the real versions in phobos to reduce the maintenance cost). Shame to just get rid of it if there are some people who might use it as is.