D calculation:

  writefln("%12.2F",log(1-0.9999)/log(1-(1-0.6)^^20));

837675572.38

C++ calculation:

  cout<<setprecision(12)<< (log(1-0.9999)/log(1-pow(1-0.6,20))) <<'\n';

837675573.587

As a second data point, changing 0.9999 to 0.75 yields 126082736.96 (Dlang) vs 126082737.142 (C++).

The discrepancy stood out as I was ultimately taking the ceil of the results and noticed an off by one anomaly. Testing with octave, www.desmos.com/scientific, and libreoffice(calc) gave results consistent with the C++ result. Is the dlang calculation within the error bound of what double precision should yield?

On Tue, Oct 29, 2019 at 4:45 PM Twilight via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>
> D calculation:
>
>    writefln("%12.2F",log(1-0.9999)/log(1-(1-0.6)^^20));
>
> 837675572.38
>
> C++ calculation:
>
>    cout<<setprecision(12)<< (log(1-0.9999)/log(1-pow(1-0.6,20)))
> <<'\n';
>
> 837675573.587
>
> As a second data point, changing 0.9999 to 0.75 yields
> 126082736.96 (Dlang) vs 126082737.142 (C++).
>
> The discrepancy stood out as I was ultimately taking the ceil of the results and noticed an off by one anomaly. Testing with octave, www.desmos.com/scientific, and libreoffice(calc) gave results consistent with the C++ result. Is the dlang calculation within the error bound of what double precision should yield?

If you use gdc or ldc you will get same results as c++, or you can use C log directly:

import std.stdio;
import std.math : pow;
import core.stdc.math;

void main()
{
     writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
}

On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak <kozzi11@gmail.com> wrote:
>
>
> If you use gdc or ldc you will get same results as c++, or you can use C log directly:
>
> import std.stdio;
> import std.math : pow;
> import core.stdc.math;
>
> void main()
> {
>      writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
> }

AFAIK dmd use real  for floating point operations instead of double

On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak <kozzi11@gmail.com> wrote:
>
> On Tue, Oct 29, 2019 at 4:45 PM Twilight via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
> >
> > D calculation:
> >mport std.stdio;
import std.math : pow;
import core.stdc.math;

void main()
{
     writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
}
> >    writefln("%12.2F",log(1-0.9999)/log(1-(1-0.6)^^20));
> >
> > 837675572.38
> >
> > C++ calculation:
> >
> >    cout<<setprecision(12)<< (log(1-0.9999)/log(1-pow(1-0.6,20)))
> > <<'\n';
> >
> > 837675573.587
> >
> > As a second data point, changing 0.9999 to 0.75 yields
> > 126082736.96 (Dlang) vs 126082737.142 (C++).
> >
> > The discrepancy stood out as I was ultimately taking the ceil of the results and noticed an off by one anomaly. Testing with octave, www.desmos.com/scientific, and libreoffice(calc) gave results consistent with the C++ result. Is the dlang calculation within the error bound of what double precision should yield?
>
> If you use gdc or ldc you will get same results as c++, or you can use C log directly:
>
> import std.stdio;
> import std.math : pow;
> import core.stdc.math;
>
> void main()
> {
>      writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
> }

My fault, for ldc and gdc you will get same result as C++ only when you use pow not ^^(operator) and use doubles:

import std.stdio;
import std.math;

void main()
{
     writefln("%12.3F",log(1-0.9999)/log((1-pow(1-0.6,20))));
}

On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
> On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak <kozzi11@gmail.com> wrote:
>>
>>
>> If you use gdc or ldc you will get same results as c++, or you can use C log directly:
>>
>> import std.stdio;
>> import std.math : pow;
>> import core.stdc.math;
>>
>> void main()
>> {
>>      writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
>> }
>
> AFAIK dmd use real  for floating point operations instead of double

Given x87 is deprecated and has been recommended against since 2003 at the latest it's hard to understand why this could be seen as a good idea.

On Tue, Oct 29, 2019 at 04:54:23PM +0000, ixid via Digitalmars-d-learn wrote:
> On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
> > On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak <kozzi11@gmail.com> wrote:
> > > If you use gdc or ldc you will get same results as c++, or you can use C log directly:
> > > 
> > > import std.stdio;
> > > import std.math : pow;
> > > import core.stdc.math;
> > > 
> > > void main()
> > > {
> > >      writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
> > > }
> > 
> > AFAIK dmd use real  for floating point operations instead of double
> 
> Given x87 is deprecated and has been recommended against since 2003 at the latest it's hard to understand why this could be seen as a good idea.

Walter talked about this recently as one of the "misses" in D (one of the things he predicted wrongly when he designed it).


T

-- 
Philosophy: how to make a career out of daydreaming.

On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
> On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak <kozzi11@gmail.com> wrote:
>>
>>
>> If you use gdc or ldc you will get same results as c++, or you can use C log directly:
>>
>> import std.stdio;
>> import std.math : pow;
>> import core.stdc.math;
>>
>> void main()
>> {
>>      writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
>> }
>
> AFAIK dmd use real  for floating point operations instead of double

Thanks for the clarification. It appears then that because of dmd's real calculations, it produces more accurate results, but maybe slower. (Calculating the result with the high precision calculator at https://keisan.casio.com/calculator agrees with dmd.)

On Tue, Oct 29, 2019 at 07:10:08PM +0000, Twilight via Digitalmars-d-learn wrote:
> On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
> > On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak <kozzi11@gmail.com> wrote:
> > > If you use gdc or ldc you will get same results as c++, or you can use C log directly:
> > > 
> > > import std.stdio;
> > > import std.math : pow;
> > > import core.stdc.math;
> > > 
> > > void main()
> > > {
> > >      writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
> > > }
> > 
> > AFAIK dmd use real  for floating point operations instead of double
> 
> Thanks for the clarification. It appears then that because of dmd's real calculations, it produces more accurate results, but maybe slower.

Yes, it will be somewhat more accurate, depending on the exact calculation you're performing. But it depends on the x87 coprocessor, which hasn't been improved for many years now, and not much attention has been paid to it, so it would appear that 64-bit double arithmetic using SIMD or MMX instructions would probably run faster.  (I'd profile it just to be sure, though. Sometimes performance predictions can be very wrong.)

So roughly speaking, if you want accuracy, use real, if you want speed, use float or double.


> (Calculating the result with the high precision calculator at https://keisan.casio.com/calculator agrees with dmd.)

To verify accuracy, it's usually safer to use an arbitrary-precision calculator instead of assuming that the most common answer is the right one (it may be far off, depending on what exactly is being computed and how, e.g., due to catastrophic cancellation and things like that). Like `bc -l` if you're running *nix, e.g. the input:

	scale=32
	l(1 - 0.9999) / l(1 - (1 - 0.6)^20)

gives:

	837675572.37859373067028812966306043501772

So it appears that the C++ answer is less accurate. Note that not all of the digits above are trustworthy; running the same calculation with scale=100 gives:

	837675572.3785937306702880546932327627909527172023597021486261165664\
	994508853029795054669322261827298817174322

which shows a divergence in digits after the 15th decimal, meaning that the subsequent digits are probably garbage values. This is probably because the logarithm function near 0 is poorly-conditioned, so you could potentially be getting complete garbage from your floating-point operations if you're not careful.

Floating-point is a bear. Every programmer should learn to tame it lest they get mauled:

	https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

:-D


T

-- 
May you live all the days of your life. -- Jonathan Swift

On Tuesday, 29 October 2019 at 16:20:21 UTC, Daniel Kozak wrote:
> On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak <kozzi11@gmail.com> wrote:
>>
>> On Tue, Oct 29, 2019 at 4:45 PM Twilight via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>> >
>> > D calculation:
>> >mport std.stdio;
> import std.math : pow;
> import core.stdc.math;
>
> void main()
> {
>      writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
> }
>> >    writefln("%12.2F",log(1-0.9999)/log(1-(1-0.6)^^20));
>> >
>> > 837675572.38
>> >
>> > C++ calculation:
>> >
>> >    cout<<setprecision(12)<< (log(1-0.9999)/log(1-pow(1-0.6,20)))
>> > <<'\n';
>> >
>> > 837675573.587
>> >
>> > As a second data point, changing 0.9999 to 0.75 yields
>> > 126082736.96 (Dlang) vs 126082737.142 (C++).
>> >
>> > The discrepancy stood out as I was ultimately taking the ceil of the results and noticed an off by one anomaly. Testing with octave, www.desmos.com/scientific, and libreoffice(calc) gave results consistent with the C++ result. Is the dlang calculation within the error bound of what double precision should yield?
>>
>> If you use gdc or ldc you will get same results as c++, or you can use C log directly:
>>
>> import std.stdio;
>> import std.math : pow;
>> import core.stdc.math;
>>
>> void main()
>> {
>>      writefln("%12.3F",log(1-0.9999)/log(1-(1-0.6)^^20));
>> }
>
> My fault, for ldc and gdc you will get same result as C++ only when you use pow not ^^(operator) and use doubles:
>
> import std.stdio;
> import std.math;
>
> void main()
> {
>      writefln("%12.3F",log(1-0.9999)/log((1-pow(1-0.6,20))));
> }

The real issue here IMO is that there's still only a `real` version of std.math.log. If there were proper double and float overloads, like for other std.math functions, the OP would get the expected result with his double inputs, and we wouldn't be having this discussion.

For LDC, it would only mean uncommenting 2 one-liners forwarding to the LLVM intrinsic; they're commented because otherwise you'd get different results with LDC compared to DMD, and other forum threads/bugzillas/GitHub issues would pop up.

Note that there's at least one bugzilla for these float/double math overloads already. For a start, one could simply wrap the corresponding C functions.

On 2019-10-29 17:43:47 +0000, H. S. Teoh said:

> On Tue, Oct 29, 2019 at 04:54:23PM +0000, ixid via Digitalmars-d-learn wrote:
>> On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
>>> On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak <kozzi11@gmail.com> wrote:
>>> 
>>> AFAIK dmd use real for floating point operations instead of double
>> 
>> Given x87 is deprecated and has been recommended against since 2003 at
>> the latest it's hard to understand why this could be seen as a good
>> idea.
> 
> Walter talked about this recently as one of the "misses" in D (one of
> the things he predicted wrongly when he designed it).

Why should the real type be a wrong decision? Maybe the code generation should be optimized if all terms are double to avoid x87 but overall more precision is better for some use-cases.

I'm very happpy it exists, and x87 too because our app really needs this extended precision. I'm not sure what we would do if we only had doubles.

I'm not aware of any 128 bit real implementations done using SIMD instructions which get good speed. Anyone?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster