www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.math log and family

reply Joe <jma freedomcircle.com> writes:
I've discovered that the 'log' function as well several similar 
functions are only defined as taking a real argument and 
returning a real, unlike most other std.math functions, which 
have triple definitions (also supporting double and float types). 
This created a problem when I tried compiling code like the 
following:

---
import std.math;

alias double function(double) Funcptr;

Funcptr sinptr = &sin;
Funcptr tanptr = &tan;
Funcptr logptr = &log;
---

dmd (and ldc2) report

test.d(7): Error: cannot implicitly convert expression & log of 
type real function(real x) pure nothrow  nogc  safe to double 
function(double)

[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]

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.  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?

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?
Oct 30 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 31, 2018 at 12:48:03AM +0000, 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 = &mylog;



 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".
Oct 30 2018
prev sibling parent reply kinke <noone nowhere.com> writes:
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.
Oct 30 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 31, 2018 at 01:14:37AM +0000, 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

-- 
Любишь кататься - люби и саночки возить.
Oct 30 2018
parent reply kinke <kinke libero.it> writes:
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
Oct 31 2018
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 31, 2018 at 11:29:17AM +0000, 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
Oct 31 2018