On 29 June 2014 15:59, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 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
>

I would have thought money would use fixed point decimal floats.

Iain

On Sunday, 29 June 2014 at 15:51:03 UTC, Iain Buclaw via Digitalmars-d wrote:
> I would have thought money would use fixed point […] floats.

Huh? ;)

David

On 6/29/14, 8:50 AM, Iain Buclaw via Digitalmars-d wrote:
> On 29 June 2014 15:59, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> 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
>>
>
> I would have thought money would use fixed point decimal floats.

And what meaningful computation can you do with such? Using fixed point for money would be like the guy in Walter's story rounding to two decimals after each step in the calculation.

Even for a matter as simple as average price for a share bought in multiple batches you need floating point.


Andrei

On Sun, 2014-06-29 at 07:59 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]

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

Very definitely so. Fixed point or integer arithmetic for simple "household" finance fair enough, but for "finance house" calculations you generally need 22+ significant denary digits to meet with compliance requirements.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2014-06-28 at 17:41 -0700, Walter Bright via Digitalmars-d wrote:
> On 6/28/2014 5:43 AM, Element 126 wrote:
> > +1 for float32 & cie. These names are much more explicit than the current ones.
> 
> I don't see any relevance to this discussion with whether 32 bit floats are named 'float' or 'float32'.

This is getting way off the original thread, but…

The issue is what hardware representations are supported: what does float mean? This is a Humpty Dumpty situation and "something must be done". Hence Go stops with the undefined words and gives definite global meanings to type names. It would be helpful if D eschewed the C/C++ heritage as well and got more definite about type names.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2014-06-28 at 17:40 -0700, Walter Bright via Digitalmars-d wrote:
> On 6/28/2014 3:33 AM, Russel Winder via Digitalmars-d wrote:
> > By being focused on Intel chips, D has failed to get floating point correct in avery analogous way to C failing to get floating point types right by focusing on PDP.
> 
> Sorry, I do not follow the reasoning here.

By being focused on specific hardware, you create names for types that do not port to other hardware. C and C++ really do not work well on IBM hardware because the PDP heritage of the type names does not port from PDP to IBM hardware.

> > Yes using 80-bit on Intel is good, but no-one
> > else has this. Floating point sizes should be 32-, 64-, 128-, 256-bit,
> > etc. D needs to be able to handle this. So does C, C++, Java, etc. Go
> > will be able to handle it when it is ported to appropriate hardware as
> > they use float32, float64, etc. as their types. None of this float,
> > double, long double, double double rubbish.
> >
> > So D should perhaps make a breaking change and have types int32, int64, float32, float64, float80, and get away from the vagaries of bizarre type relationships with hardware?
> 
> D's spec says that the 'real' type is the max size supported by the FP hardware. How is this wrong?

Because when reading the code you haven't got a f####### clue how accurate the floating point number is until you ask and answer the question "and which processor are you running this code on".

In many ways this is a trivial issue given C and C++ heritage, on the other hand Go and other languages are changing the game such that C and C++ thinking is being left behind.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 29 June 2014 at 18:17:06 UTC, Russel Winder via Digitalmars-d wrote:
> This is getting way off the original thread, but…
>
> The issue is what hardware representations are supported: what does
> float mean? This is a Humpty Dumpty situation and "something must be
> done". Hence Go stops with the undefined words and gives definite global
> meanings to type names. It would be helpful if D eschewed the C/C++
> heritage as well and got more definite about type names.

There is nothing Humpty Dumpty about the current situation. You are simply missing the fact that float and double are already defined as 32 bit/64 bit IEEE 754 compliant floating point numbers in the spec.

There is nothing ambiguous about that, just as char/int/long have defined bit-widths in D.

David

On 6/29/2014 9:54 AM, Andrei Alexandrescu wrote:
> On 6/29/14, 8:50 AM, Iain Buclaw via Digitalmars-d wrote:
>> On 29 June 2014 15:59, Andrei Alexandrescu via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> 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
>>>
>>
>> I would have thought money would use fixed point decimal floats.
>
> And what meaningful computation can you do with such? Using fixed point for
> money would be like the guy in Walter's story rounding to two decimals after
> each step in the calculation.
>
> Even for a matter as simple as average price for a share bought in multiple
> batches you need floating point.

I can see using floating point for the calculation, but the final result should be stored as whole pennies.

On 6/29/2014 11:13 AM, Russel Winder via Digitalmars-d wrote:
> On Sun, 2014-06-29 at 07:59 -0700, Andrei Alexandrescu via Digitalmars-d
> wrote:
> […]
>
>> 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.
>
> Very definitely so. Fixed point or integer arithmetic for simple
> "household" finance fair enough, but for "finance house" calculations
> you generally need 22+ significant denary digits to meet with compliance
> requirements.

Doubles are only good to 17 digits, and even that 17th digit is flaky.

On 6/29/2014 12:02 PM, David Nadlinger wrote:
> On Sunday, 29 June 2014 at 18:17:06 UTC, Russel Winder via Digitalmars-d wrote:
>> This is getting way off the original thread, but…
>>
>> The issue is what hardware representations are supported: what does
>> float mean? This is a Humpty Dumpty situation and "something must be
>> done". Hence Go stops with the undefined words and gives definite global
>> meanings to type names. It would be helpful if D eschewed the C/C++
>> heritage as well and got more definite about type names.
>
> There is nothing Humpty Dumpty about the current situation. You are simply
> missing the fact that float and double are already defined as 32 bit/64 bit IEEE
> 754 compliant floating point numbers in the spec.
>
> There is nothing ambiguous about that, just as char/int/long have defined
> bit-widths in D.

Exactly. C/C++ has implementation-defined types, but D types are nailed down.