On 2019-10-31 16:07:07 +, H. S. Teoh said:
Maybe you might be interested in this:
https://stackoverflow.com/questions/6769881/emulate-double-using-2-floats
Thanks, I know the 2nd mentioned paper.
Maybe switch to PPC? :-D
Well, our customers don't use PPC Laptops ;-) otherwise
On Thu, Oct 31, 2019 at 09:52:08AM +0100, Robert M. Münch via
Digitalmars-d-learn wrote:
> On 2019-10-30 15:12:29 +, H. S. Teoh said:
[...]
> > Do you mean *simulated* 128-bit reals (e.g. with a pair of 64-bit
> > doubles), or do you mean actual IEEE 128-bit reals?
>
> Simulated, because HW s
On 2019-10-30 15:12:29 +, H. S. Teoh said:
It wasn't a wrong *decision* per se, but a wrong *prediction* of where
the industry would be headed.
Fair point...
Walter was expecting that people would move towards higher precision,
but what with SSE2 and other such trends, and the general ne
On Wed, Oct 30, 2019 at 09:03:49AM +0100, Robert M. Münch via
Digitalmars-d-learn wrote:
> On 2019-10-29 17:43:47 +, H. S. Teoh said:
>
> > On Tue, Oct 29, 2019 at 04:54:23PM +, ixid via Digitalmars-d-learn
> > wrote:
> > > On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
On Tuesday, 29 October 2019 at 20:15:13 UTC, kinke wrote:
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.
I guess, that this issue:
https://issues.dlang.org/show_bug.cgi?id=20206 boils dow
On 2019-10-29 17:43:47 +, H. S. Teoh said:
On Tue, Oct 29, 2019 at 04:54:23PM +, 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 wrote:
AFAIK dmd use real for floating point operations i
On Tuesday, 29 October 2019 at 16:20:21 UTC, Daniel Kozak wrote:
On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak
wrote:
On Tue, Oct 29, 2019 at 4:45 PM Twilight via
Digitalmars-d-learn wrote:
>
> D calculation:
>mport std.stdio;
import std.math : pow;
import core.stdc.math;
void main()
{
On Tue, Oct 29, 2019 at 07:10:08PM +, 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 wrote:
> > > If you use gdc or ldc you will get same results as c++, or you can
> > > use C log dir
On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak
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()
{
wr
On Tue, Oct 29, 2019 at 04:54:23PM +, 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 wrote:
> > > If you use gdc or ldc you will get same results as c++, or you can
> > > use C log directly
On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote:
On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak
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()
{
wr
On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak wrote:
>
> On Tue, Oct 29, 2019 at 4:45 PM Twilight via Digitalmars-d-learn
> wrote:
> >
> > D calculation:
> >mport std.stdio;
import std.math : pow;
import core.stdc.math;
void main()
{
writefln("%12.3F",log(1-0.)/log(1-(1-0.6)^^20));
}
> >
On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak 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.)/log(1-(1-0.6)^^20));
On Tue, Oct 29, 2019 at 4:45 PM Twilight via Digitalmars-d-learn
wrote:
>
> D calculation:
>
>writefln("%12.2F",log(1-0.)/log(1-(1-0.6)^^20));
>
> 837675572.38
>
> C++ calculation:
>
>cout< <<'\n';
>
> 837675573.587
>
> As a second data point, changing 0. to 0.75 yields
> 126082736
D calculation:
writefln("%12.2F",log(1-0.)/log(1-(1-0.6)^^20));
837675572.38
C++ calculation:
cout<<<'\n';
837675573.587
As a second data point, changing 0. to 0.75 yields
126082736.96 (Dlang) vs 126082737.142 (C++).
The discrepancy stood out as I was ultimately taking the ce
On 07/22/2019 08:48 PM, Timon Gehr wrote:
> This is probably not your problem, but it may be good to know anyway: D
> allows compilers to perform arbitrary "enhancement" of floating-point
> precision for parts of the computation, including those performed at
> compile time. I think this is stupid
On 22.07.19 14:49, drug wrote:
I have almost identical (I believe it at least) implementation (D and
C++) of the same algorithm that uses Kalman filtering. These
implementations though show different results (least significant
digits). Before I start investigating I would like to ask if this is
22.07.2019 17:19, drug пишет:
22.07.2019 16:26, Guillaume Piolat пишет:
Typical floating point operations in single-precision like a simple
(a * b) + c will provide a -140dB difference if order is changed.
It's likely the order of operations is not the same in your program,
so the least sign
22.07.2019 16:26, Guillaume Piolat пишет:
Typical floating point operations in single-precision like a simple (a
* b) + c will provide a -140dB difference if order is changed. It's
likely the order of operations is not the same in your program, so the
least significant digit should be differe
On Monday, 22 July 2019 at 12:49:24 UTC, drug wrote:
Before I start investigating I would like to ask if this issue
(different results of floating points calculation for D and
C++) is well known?
This likely has little to do with the language, and more with the
implementation. Basic floating
On Monday, 22 July 2019 at 13:23:26 UTC, Guillaume Piolat wrote:
On Monday, 22 July 2019 at 12:49:24 UTC, drug wrote:
I have almost identical (I believe it at least) implementation
(D and C++) of the same algorithm that uses Kalman filtering.
These implementations though show different results
On Monday, 22 July 2019 at 12:49:24 UTC, drug wrote:
I have almost identical (I believe it at least) implementation
(D and C++) of the same algorithm that uses Kalman filtering.
These implementations though show different results (least
significant digits). Before I start investigating I would
On 23/07/2019 12:58 AM, drug wrote:
22.07.2019 15:53, rikki cattermole пишет:
https://godbolt.org/z/EtZLG0
hmm, in short - this is my local problem?
That is not how I would describe it.
I would describe it as IEEE-754 doing what IEEE-754 is good at.
But my point is, you can get the results
22.07.2019 15:53, rikki cattermole пишет:
https://godbolt.org/z/EtZLG0
hmm, in short - this is my local problem?
On 23/07/2019 12:49 AM, drug wrote:
I have almost identical (I believe it at least) implementation (D and
C++) of the same algorithm that uses Kalman filtering. These
implementations though show different results (least significant
digits). Before I start investigating I would like to ask if th
I have almost identical (I believe it at least) implementation (D and
C++) of the same algorithm that uses Kalman filtering. These
implementations though show different results (least significant
digits). Before I start investigating I would like to ask if this issue
(different results of float
26 matches
Mail list logo
