Re: std.math log and family

2018-10-31 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Oct 31, 2018 at 11:29:17AM +, kinke via Digitalmars-d-learn wrote:
> On Wednesday, 31 October 2018 at 01:26:19 UTC, H. S. Teoh wrote:
> > Is it true that on modern hardware computing with `real` reverts to
> > slow x87 emulation in the CPU instead of using SSE/MMX/whatever
> > native math functions?
> 
> You should have read recent DMD & LDC release notes. ;)
> https://github.com/dlang/phobos/pull/6272#issuecomment-373967109

Ah, very nice!  Thanks for the link.


T

-- 
Public parking: euphemism for paid parking. -- Flora


Re: std.math log and family

2018-10-31 Thread kinke via Digitalmars-d-learn

On Wednesday, 31 October 2018 at 01:26:19 UTC, H. S. Teoh wrote:
Is it true that on modern hardware computing with `real` 
reverts to slow x87 emulation in the CPU instead of using 
SSE/MMX/whatever native math functions?


You should have read recent DMD & LDC release notes. ;)
https://github.com/dlang/phobos/pull/6272#issuecomment-373967109


Re: std.math log and family

2018-10-30 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Oct 31, 2018 at 01:14:37AM +, kinke via Digitalmars-d-learn wrote:
> On Wednesday, 31 October 2018 at 00:48:03 UTC, Joe wrote:
> > I'd like to know if the lack of double/float versions of 'log',
> > 'log10', etc. are intentional, i.e., there's some rationale behind
> > it, or an oversight.
> 
> Just laziness or people still thinking that you don't lose any
> performance by computing in `real` precision.

Is it true that on modern hardware computing with `real` reverts to slow
x87 emulation in the CPU instead of using SSE/MMX/whatever native math
functions?  I've heard that said a lot, I'm just wondering if there's
actual measurements to back that up.


[...]
> > I'd also like to know the proper/best way to deal with the error
> 
> Long-term? Definitely adding the missing implementations to std.math ;),
> continuing my work here: https://github.com/dlang/phobos/pull/6272
> Short-term, I'd go with tiny wrappers.

Yeah, going forward std.math definitely needs to have native
float/double counterparts for all functions.  Preferably CTFE-eable
versions of them all, so that I can compute my math lookup tables at
compile-time. :-D


T

-- 
Любишь кататься - люби и саночки возить. 


Re: std.math log and family

2018-10-30 Thread kinke via Digitalmars-d-learn

On Wednesday, 31 October 2018 at 00:48:03 UTC, Joe wrote:
I'd like to know if the lack of double/float versions of 'log', 
'log10', etc. are intentional, i.e., there's some rationale 
behind it, or an oversight.


Just laziness or people still thinking that you don't lose any 
performance by computing in `real` precision.



[ldc2 also reports
test.d(6): Error: cannot implicitly convert expression & tan of 
type real function(real x) pure nothrow @nogc @trusted to 
double function(double)

but apparently this is an LDC-only problem]


You've got to be using an older LDC version; v1.12 does define 
tan() for all 3 FP types.



I'd also like to know the proper/best way to deal with the error


Long-term? Definitely adding the missing implementations to 
std.math ;), continuing my work here: 
https://github.com/dlang/phobos/pull/6272

Short-term, I'd go with tiny wrappers.


Re: std.math log and family

2018-10-30 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Oct 31, 2018 at 12:48:03AM +, Joe via Digitalmars-d-learn wrote:
[...]
> I'd like to know if the lack of double/float versions of 'log',
> 'log10', etc. are intentional, i.e., there's some rationale behind it,
> or an oversight.

It's an oversight.  Thanks for bringing it to our attention.

Well, actually there's a historical reason behind it, but that's no
excuse.  Please file a bug against Phobos here:

http://issues.dlang.org/


> I'd also like to know the proper/best way to deal with the error,
> considering the real code embeds the 'Funcptr's in an array of
> structs.  Is it better to write a function 'mylog' that internally
> casts the argument and the return value, or is there some safe way to
> cast away the 'log' function at the point of initializing the array?

I don't think it's safe to cast the function pointer, because of
mismatching types. You might get undefined behaviour at runtime. Define
your own wrapper instead, as you said, that just forwards the
implementation to std.math.log. You don't need to cast the argument
because it implicitly promotes to real anyway:

float mylog(float arg) { return std.math.log(arg); }
auto funcptr = 


> Also, is it preferable to post the first question
> (intentional/oversight) in the Phobos forum? And what is the preferred
> way of reporting the LDC problem, via GitHub?

If you're unsure, just ask on the forum. :)

In this case, this is a bug in Phobos itself, so an issue should be
filed at: http://issues.dlang.org/

(While discussion on the forum may be helpful, always remember to file
an issue, because forum discussions may get forgotten after some time,
whereas issues in the bug tracker will eventually get looked at. Don't
be shy to clamor on the forum about bugs that nobody has responded to in
a long time, though.  Sometimes things get overlooked and we just need
a reminder.)


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see 
through walls. It was called the "window".