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?

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.

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

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.

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

-- 
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 Saturday, 31 October 2015 at 15:42:00 UTC, tcak 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.

Bigint îs enough only for addition or subtraction as long as you keep a commonly agreed constant scale. Once you need multiplication, division or rounding, managing a dynamic scale can be very messy.

IEEE standard is also divided between two standard formats: DPD preferred by IBM and BID preferred by Intel.

Currently a DPD partial implementation is available on code.dlang.org; Unfortunately it's not updated since 4 months. The author proposed this for phobos integration without success.

My opinion is that a decimal data type must be builtin in any modern language, not implemented as a library.

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.

I agree

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

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

Isn't D used by a rather large banking company internally? I believe I remember this being mentioned somewhere.

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

C# - built-in decimal data type 128 bit (96 bit significand + 32 bit sign and scale) - https://msdn.microsoft.com/en-us/library/364x0z75.aspx
GNU C - 3 built-in decimal data types - https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html

Besides that, according to the last IEEE-2008 standard, any language must implement decimal floating point support at the same level of binary float support. Once al language has float, double and real, must also define decimal counterparts - decimal32, decimal64 and decimal128.

Concerning the advantages of a built-in data type, it happens to work right now to a decimal BID floating point implementation, here is a list of problems I encountered during development:

- literals - right now the only way to define literals is a templated string, using float literals will result in precision loss, since binary floating point cannot be represented exactly.
- correct comparison operators - operator overloading doesn't allow unordered comparisons similar to binary data types. Comparing any NaN, must always return false, implementing opEquals is not enough is this case, since a != b is equivalent to !(a == b)
- implicit casting cannot be defined - a decimal32 must be implicitly convertible to decimal64 and a decimal64 must be implicitly convertible to decimal128.
- using a global DecimalContext (according to IEEE standard) - similar to std.math.FloatingPointControl, will make all your functions impure. Throwing exceptions according also to IEEE standard will make any calculation garbage collected. The compiler can override this behaviour as it's doing in the binary floating point case, they are also using a global context and throw exceptions.
- BigInt is unsuitable as backend for decimal128 data type since it allocates on overflow, therefore all your operations will be garbage collected. Also BigInt is using uint arrays as backend, there is no performance optimisation for 64 bit arithmetic, that's why is slow. Adding a scale to the BigInt is not enough, once you need to multiply values with high-precision percents, you must keep all your numbers scaled to many, many digits resulting in very poor performance.
- Efficient 128 bit arithmetic is missing since ucent is not implemented and the decimal128 data type is heavily built on it. Writing your own 128 bit data type will have the same disadvantages as exposed above. As a fun fact, through trial and error, I discovered that a FPU division is faster than the Newton–Raphson applied to wide integral data types. Probably, a fine tuned assembler implementation is faster than that. Since there are operations calculated using unlimited precision like fma(), there is also need for efficient >128 bit arithmetic.
- Impurity and garbage collection being involved, the CTFE is not always available.
- Heavily templating your code to cover all three decimal data types, will result in unintelligible compiler errors like "Out of memory" and will render features like code completion useless. Using mixins will break out syntax highlighting, code completion and documentation; to cope with that you will finally copy-paste code all over the place.
- you cannot interfere with compiler optimisations, eg comparing a decimal value to 0 in certain cases can be done with a simple bit test, instead of a fully featured function, even inlined.

Yes, I'm working in the "very fringe sector of users" - financial apps. So banks, insurance companies, investment funds and accounting firms are a very fringe sector. In most cases they are using Java for development, a very fringe language. Good to know that.