On Sunday, 29 June 2014 at 04:38:31 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Jun 28, 2014 at 05:16:53PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 6/28/2014 3:57 AM, Russel Winder via Digitalmars-d wrote:
> [...]
>> >Or indeed when calculating anything to do with money.
>> 
>> You're better off using 64 bit longs counting cents to represent money
>> than using floating point. But yeah, counting money has its own
>> special problems.
>
> For counting money, I heard that the recommendation is to use
> fixed-point arithmetic (i.e. integer values in cents).
>
>
> T

MtGox was using float.

On Sat, Jun 28, 2014 at 08:41:24PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/28/14, 6:02 PM, Tofu Ninja wrote:
[...]
> >I think this thread needs to refocus on the main point, getting math overloads for float and double and how to mitigate any problems that might arise from that.
> 
> Yes please. -- Andrei

Let's see the PR!

And while we're on the topic, what about working on making std.math CTFE-able? So far, CTFE simply doesn't support fundamental floating-point operations like isInfinity, isNaN, signbit, to name a few, because CTFE does not allow accessing the bit representation of floating-point values. This is a big disappointment for me -- it defeats the power of CTFE by making it unusable if you want to use it to generate pre-calculated tables of values.

Perhaps we can introduce some intrinsics for implementing these functions so that they work both in CTFE and at runtime?

	https://issues.dlang.org/show_bug.cgi?id=3749

Thanks to Iain's hard work on std.math, now we have software implementations for all(?) the basic math functions, so in theory they should be CTFE-able -- except that some functions require access to the floating-point bit representation, which CTFE doesn't support. All it takes is to these primitives, and std.math will be completely CTFE-able -- a big step forward IMHO.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius

On Sunday, 29 June 2014 at 00:16:51 UTC, Walter Bright wrote:
> On 6/28/2014 3:57 AM, Russel Winder via Digitalmars-d wrote:
>
>> Or indeed when calculating anything to do with money.
>
> You're better off using 64 bit longs counting cents to represent money than using floating point. But yeah, counting money has its own special problems.

Maybe if by "money" you mean dollars in the bank.  But for anything much beyond that you're doing floating point math.  Often with specific rules for how and when rounding should occur.  Perhaps interestingly, it's typical for hedge funds to have a "rounding partner" who receives all the fractional pennies that are lost when divvying up the income for the other investors.

On Saturday, 28 June 2014 at 05:16:29 UTC, Walter Bright wrote:
>
> That's a common perception of people who do not use the floating point unit for numerical work, and whose main concern is speed instead of accuracy.
>
> <snip>
>
> > I find it's extremely rare to have precision problems even
> with float under most normal usage
> > circumstances,
>
> Then you aren't doing numerical work, because it happens right away.

There is of course many situations where a high precision is necessary. But in these situations you have 'real' available to you, which presumably would maintain as high precision as is possible. In the situations where you're using float/double, you should not be expecting maximum precision and instead performance should be focused on. There are existing overloads for 'real' in std.math that presumably would not go away, the only need now is to add new overloads for float/double that can take advantage of SSE instructions. While striving for precision is nice, in a huge majority of situations it's simply not necessary (and when it is, 'real' will be used). It makes D look bad when it does so poorly on benchmarks like this simply so that the output perlin noise can be rounded from 238.32412319 to 238 instead of 238.32 to 238.

On 6/28/2014 9:36 PM, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Jun 28, 2014 at 05:16:53PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 6/28/2014 3:57 AM, Russel Winder via Digitalmars-d wrote:
> [...]
>>> Or indeed when calculating anything to do with money.
>>
>> You're better off using 64 bit longs counting cents to represent money
>> than using floating point. But yeah, counting money has its own
>> special problems.
>
> For counting money, I heard that the recommendation is to use
> fixed-point arithmetic (i.e. integer values in cents).

I think that's what I said :-)

On 29 Jun 2014 05:48, "H. S. Teoh via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Sat, Jun 28, 2014 at 08:41:24PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
> > On 6/28/14, 6:02 PM, Tofu Ninja wrote:
> [...]
> > >I think this thread needs to refocus on the main point, getting math overloads for float and double and how to mitigate any problems that might arise from that.
> >
> > Yes please. -- Andrei
>
> Let's see the PR!
>

I've already raised one (already linked in this thread).

More to come!

> And while we're on the topic, what about working on making std.math CTFE-able? So far, CTFE simply doesn't support fundamental floating-point operations like isInfinity, isNaN, signbit, to name a few, because CTFE does not allow accessing the bit representation of floating-point values.

As it stands, as soon as the above mentioned PR for Phobos is merged, isNaN and isInfinite on float and double types will be CTFE-able. However that depends on whether or not float->int painting will be replaced with a union.

> This is a big disappointment for me -- it defeats
> the power of CTFE by making it unusable if you want to use it to
> generate pre-calculated tables of values.
>
> Perhaps we can introduce some intrinsics for implementing these functions so that they work both in CTFE and at runtime?
>
>         https://issues.dlang.org/show_bug.cgi?id=3749
>

CTFE support for accessing basic types in unions - as in painting between all kinds of scalar types, with special support for static arrays (via vectors) should be all that is required.

Once CTFE supports that, it won't be difficult to get std.math to be CTFE-certified. :)

> Thanks to Iain's hard work on std.math, now we have software implementations for all(?) the basic math functions, so in theory they should be CTFE-able -- except that some functions require access to the floating-point bit representation, which CTFE doesn't support. All it takes is to these primitives, and std.math will be completely CTFE-able -- a big step forward IMHO.
>

The original goal was making std.math non-asm implementations *genuinely* pure/nothrow/@safe for GDC x86, and for other ports like ARM, SPARC so LDC benefits also.

Andrei was the one who sold me on the idea if making them CTFE-able. However,  I stopped just short of that goal because of this missing feature of DMD - though I did implement it in GDC as proof of concept that it is possible (code not actually published anywhere)

There should be a bug report somewhere that I outlined the exact steps in.

Regards
Iain.

On Sunday, 29 June 2014 at 00:22:02 UTC, Walter Bright wrote:
> On 6/28/2014 4:27 AM, francesco cattoglio wrote:
>> We are talking about paying a price when you don't need it.
>
> More than that - the suggestion has come up here (and comes up repeatedly) to completely remove support for 80 bits. Heck, Microsoft has done so with VC++ and even once attempted to completely remove it from 64 bit Windows (I talked them out of it, you can thank me!).

Then I must have missed the post. Removing 80 bit support would sound like madness to my ears.
And about that Microsoft thing, thanks a lot :o)

On Sunday, 29 June 2014 at 04:46:49 UTC, deadalnix wrote:
> On Sunday, 29 June 2014 at 04:38:31 UTC, H. S. Teoh via Digitalmars-d wrote:
>> On Sat, Jun 28, 2014 at 05:16:53PM -0700, Walter Bright via Digitalmars-d wrote:
>>> On 6/28/2014 3:57 AM, Russel Winder via Digitalmars-d wrote:
>> [...]
>>> >Or indeed when calculating anything to do with money.
>>> 
>>> You're better off using 64 bit longs counting cents to represent money
>>> than using floating point. But yeah, counting money has its own
>>> special problems.
>>
>> For counting money, I heard that the recommendation is to use
>> fixed-point arithmetic (i.e. integer values in cents).
>>
>>
>> T
>
> MtGox was using float.

LOL ;-)

---
Paolo

On 6/29/2014 12:57 AM, francesco cattoglio wrote:
> And about that Microsoft thing, thanks a lot :o)

Welcs!

On 6/28/14, 9:36 PM, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Jun 28, 2014 at 05:16:53PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 6/28/2014 3:57 AM, Russel Winder via Digitalmars-d wrote:
> [...]
>>> Or indeed when calculating anything to do with money.
>>
>> You're better off using 64 bit longs counting cents to represent money
>> than using floating point. But yeah, counting money has its own
>> special problems.
>
> For counting money, I heard that the recommendation is to use
> fixed-point arithmetic (i.e. integer values in cents).

A friend who works at a hedge fund (after making the rounds to the NYC large financial companies) told me that's a myth. Any nontrivial calculation involving money (interest, fixed income, derivatives, ...) needs floating point. He never needed more than double.

Andrei