On Saturday, 31 October 2015 at 23:07:46 UTC, rumbu wrote:
> On Saturday, 31 October 2015 at 20:55:33 UTC, David Nadlinger wrote:
>> On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:
>>> My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library.
>>
>> "must be builtin in any modern language" – which modern languages actually have decimals as a built-in type, and what is your rationale against having them as a solid library implementation? It seems like it would only be interesting for a very fringe sector of users (finance, and only the part of it that actually deals with accounting).
>>
>>  — David
> GNU C - 3 built-in decimal data types - https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html

This is a vendor-specific extension and likely exposed by GDC already.

On 10/31/2015 09:06 AM, Russel Winder via Digitalmars-d-learn wrote:

> As far as I am aware only IBM Big Iron (aka mainframes, aka z-Series) has
> hardware decimal floating point these days. (Even though 1970s and 1980s
> microprocessors had the feature.)

Although still years away from production, the Mill CPU will have decimal floating point:

  http://millcomputing.com/wiki/Instruction_Set

Ali

On Sat, 2015-10-31 at 20:55 +0000, David Nadlinger via Digitalmars-d- learn wrote:
> On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:
> > My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library.
> 
> "must be builtin in any modern language" – which modern languages actually have decimals as a built-in type, and what is your rationale against having them as a solid library implementation? It seems like it would only be interesting for a very fringe sector of users (finance, and only the part of it that actually deals with accounting).
> 
>   — David

It is really a question of symmetry: if there are hardware implementations of both binary and denary floating point, then if a language has binary floating point in the language, then it should have denary floating point in the language. To support one hardware type in the language but relegate another hardware type to the library is inappropriate discrimination.

If I remember correctly (I am on a very poor Internet connection just now and can't do the necessary research), IBM z-series has two different denary hardware types, and there is currently a question as to which of these to draw into the IEEE standard as the preferred type. I think Intel are muttering about which one to support.

-- 
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 Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:
> Any other thoughts?

Floating point operations can be extended automatically (without some kind of 'fastmath' flag) up to 80bit fp on 32 bit intel processors. This is worst solution for language that want to be used in accounting or math.

Thoughts like "larger precision entails more accurate answer" are naive and wrong.

--Ilya

On Saturday, 31 October 2015 at 23:16:04 UTC, Ali Çehreli wrote:
> Although still years away from production, the Mill CPU will have decimal floating point:
>
>   http://millcomputing.com/wiki/Instruction_Set


Mill is a fun project, and there are also base 10 floating point FPGA coprocessors available, but probably not widely deployed.

I've personally settled for storing in cents instead, as integers have accurate precision (storing "30.0" instead of "0.3"). The problem is then reduced to writing a wrapper for floats with a dedicated string_to_float conversion that is loss free.

On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:
> I'm writing a talk for codemesh on the use of D in finance.
>
> I want to start by addressing the good reasons not to use D.  (We all know what the bad ones are).  I don't want to get into a discussion here on them, but just wanted to make sure I cover them so I represent the state of affairs correctly.
>
> So far what comes to mind: heavy GUI stuff (so far user interface code is not what it could be); cases where you want to write quick one-off scripts that need to use a bunch of different libraries not yet available in D and where it doesn't make sense to wrap or port them; where you have a lot of code in another language (especially non C, non Python) and defining an interface is not so easy; where you have many inexperienced programmers and they need to be productive very quickly.
>
> Any other thoughts?

I would advise against using D in applications where memory is essential. Idiomatic D uses a garbage collector which has a non free runtime cost.

On Saturday, 31 October 2015 at 05:25:06 UTC, ref2401 wrote:
> On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:
>> I'm writing a talk for codemesh on the use of D in finance.
>>
>> I want to start by addressing the good reasons not to use D.  (We all know what the bad ones are).  I don't want to get into a discussion here on them, but just wanted to make sure I cover them so I represent the state of affairs correctly.
>>
>> So far what comes to mind: heavy GUI stuff (so far user interface code is not what it could be); cases where you want to write quick one-off scripts that need to use a bunch of different libraries not yet available in D and where it doesn't make sense to wrap or port them; where you have a lot of code in another language (especially non C, non Python) and defining an interface is not so easy; where you have many inexperienced programmers and they need to be productive very quickly.
>>
>> Any other thoughts?
>
> I'd suggest enterprise software because many necessary libraries and tools do not exist in D ecosystem. Though you've already named these reasons.

Thank you very much to every one who has replied on this thread, and my apologies for not engaging - just haven't had time.  But I have read them all and it will help me clarify what I say.

Incidentally, there is enterprise and enterprise.  What's necessary really depends on what you're trying to do.  For me, so far, I don't see the lack of libraries as a major problem.  How much work really is it to port some bindings?  Not much in relation to the larger goal.  I've done that myself for many of them I wanted so far, because I wanted to get to know the tools I was working with and you can't delegate learning.  In coming months others will be helping me, which will allow me to spend a bit more time and energy on the investment aspect and the bigger picture.

That's not only been my perspective, but also that of other financial adopters of languages perceived as niche - for example, Jane Street with ocaml.

A benefit of the D community that also resonates with what Yaron Minsky at Jane Street says about ocaml is that there are some very good programmers here (and the less experienced ones learn from the more experienced ones, and the reason that's possible is the very thing that turns off more corporate sorts of people - it's a small community so people have more time and energy to spend).  You couldn't buy for any price what people I have talked to have learnt by becoming language contributors...


Laeeth.

On Sunday, 1 November 2015 at 20:38:44 UTC, Freddy wrote:
> On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:
>> I'm writing a talk for codemesh on the use of D in finance.
>>
>> I want to start by addressing the good reasons not to use D.  (We all know what the bad ones are).  I don't want to get into a discussion here on them, but just wanted to make sure I cover them so I represent the state of affairs correctly.
>>
>> So far what comes to mind: heavy GUI stuff (so far user interface code is not what it could be); cases where you want to write quick one-off scripts that need to use a bunch of different libraries not yet available in D and where it doesn't make sense to wrap or port them; where you have a lot of code in another language (especially non C, non Python) and defining an interface is not so easy; where you have many inexperienced programmers and they need to be productive very quickly.
>>
>> Any other thoughts?
>
> I would advise against using D in applications where memory is essential. Idiomatic D uses a garbage collector which has a non free runtime cost.

Idiomatic D doesn't need to use the GC, and may generate much less garbage anyway.  Andrei's allocator is pretty easy to use, and EMSI containers on top make it even easier.  And those aren't the only options.

On Sunday, 1 November 2015 at 09:07:56 UTC, Ilya Yaroshenko wrote:
> On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:
>> Any other thoughts?
>
> Floating point operations can be extended automatically (without some kind of 'fastmath' flag) up to 80bit fp on 32 bit intel processors. This is worst solution for language that want to be used in accounting or math.
>
> Thoughts like "larger precision entails more accurate answer" are naive and wrong.
>
> --Ilya

Thanks, Ilya.  An important but subtle point.  Funnily enough, I haven't done so much specifically heavily numerical work so far, but trust that in the medium term the dlangscience project by John Colvin and others will bear fruit.

What would you suggest is a better option to address the concerns you raised?

On Saturday, 31 October 2015 at 16:06:47 UTC, Russel Winder wrote:
> On Sat, 2015-10-31 at 15:41 +0000, tcak via Digitalmars-d-learn wrote:
>> On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:
>> > On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:
>> > > I'm writing a talk for codemesh on the use of D in finance.
>> > > 
>> > > Any other thoughts?
>> > 
>> > For finance stuff - missing a floating point decimal data type. Things like 1.1 + 2.2 = 3.3000000000000003
>> 
>> I always thought that this type of arithmetic operations can be solved with BigInt, but never tried it. Since the issue is related to IEEE standard, a simulated (not supported by hardware directly) data type might be required.
>
> In that std.bigint.BigInt provides the accuracy, yes it does suffice. But it is slow. As far as I am aware only IBM Big Iron (aka mainframes, aka z-Series) has hardware decimal floating point these days. (Even though 1970s and 1980s microprocessors had the feature.)

It would be nice to have fixed point numbers in Phobos, although it's not much work to implement, and there is a library solution already (which is maintained, but sometimes for a while breaks with newer versions of dmd).