Re: good reasons not to use D?
On Monday, 2 November 2015 at 17:07:33 UTC, Laeeth Isharc wrote: 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? The main goal is that we need to rewrite std.math & std.mathspecial to 1. Support all FP types (float/double) 2. Be portable (no Assembler when possible!, we _can_ use CEPHES code) 3. Produce equal results on different machines with different compilers for float/double. The problem is that many math functions use compensatory hacks to make result more accurate. But this hack have _very_ bad behaviour if we allow 80bit math for double and float. Q: What we need to change? A: Only dmd backend for old intel/amd 32 bit processors without sse support. Other compilers and platforms are not affected. So, D will have the same FP behaviour like C. See also the comment: https://github.com/D-Programming-Language/phobos/pull/2991#issuecomment-74506203 -- Ilya
Re: good reasons not to use D?
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. Sorry - I wrote this in a hurry, and I should have said on my experience of using D in finance (not the whole sector, which is absolutely enormous and very diverse), and what lessons and general things might be useful for others considering D. I can imagine lack of fixed point might be a problem. Shouldn't this be in Phobos? If BigInt is, then why not fixed point? There is this library here - had some problems compiling it last time (dmd versions), but it seems at least somewhat thought-through: https://github.com/jaypha/fixed Not sure if I replied to the suggestion that D isn't suitable for enterprise use. That's a word with a nice penumbra of connotations. If you mean you shouldn't use it for a project in a multinational where thare are 100 people working on it and without extensive experience of using D by the key people already, then sure. If you mean that D isn't suitable for serious work where there are very large amounts of money at stake, and the organisation may be a decent size then I strongly disagree. The examples of Facebook's worp, Sociomantic, EMSI, and the German guys who do the Norwegian train system ought to be sufficient to make that point...
Re: good reasons not to use D?
On Tuesday, 3 November 2015 at 23:37:36 UTC, Chris wrote: On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: Interesting. Two points suggest that you should use D only for serious programming: "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" - quick and dirty "where you have many inexperienced programmers and they need to be productive very quickly." - quick and awkward [what does this tell us about financial programming ...] This reason is true of any other language: "where you have a lot of code in another language (especially non C, non Python) and defining an interface is not so easy;" In fact, the reasons you give (apart from the point about GUI) are true of C++, C#, Java etc. too. It's a bit generic. I was thinking of D specific reasons like lack of support for mobile platforms (not 100% yet). So your average stock broker couldn't calculate some bogus numbers on his iPad while having a latte and a Pelegrino in a posh cafe off Wallstreet. He he he. GC and lack of mobile are real reasons not to use D. Thanks, Chris, appreciate the feedback. I gave talk yesterday to a select but interested audience. Slides should be up soon - couple typos and as Andrei points out a bit too dense. (It's easy to forget when you read very quickly that not everyone does, and I should be more considerate of an audience). I really would have liked to have spent a bit more time preparing, as many things came together on other fronts so I had to do the best I could with the time available. You're right that I made it sound like D isn't a language for non-serious programming - well not quite, but more in that direction - and I should find a way to be clear about this anyway. Fact is I use it for scripts all the time. But if I ask myself, would I recommend it to someone who won't also use it for serious things, or has to depend on getting a bunch of junior guys with little experience (and with a low tolerance for discomfort) no I would not. [what does this tell us about financial programming ...] I'm an elitist (albeit a kind, open-hearted one), and I think that the research about the differences between productivity across almost any domain is right and underappreciated, and that it matters because if you don't recognize this then you won't organize your business so as to make it possible for these people to perform at that level. It's because of that and because the language appeals to me that I am here. Paper is here: https://www.evernote.com/shard/s37/sh/12b86414-ed93-472d-9a6f-db223087d869/62f13d679581134ef1d368d5b57cd2b7 Yaron Minsky said that at Jane Street they had the luxury of only hiring good programmers (and so the possible difficulty of ocaml simply wasn't a factor). I applaud the sentiment, and agree. This somewhat american conception of the rockstar programmer simply misses the point. That isn't how these people are, and they won't all be paid gazillions of dollars. One just has to have the discernment to recognize talent, earn its respect (which can only be if you make yourself worthy of it), provide working conditions that are suited to it, and figure out how to address the particular challenges of working with creative people. I don't know about financial programming in general - it's a really big sector and requirements are not the same. Even within my narrow little part of it, what I am doing (or at least a good part of it) is a bit different from anyone else I know, and the organizational approach and its flexibility is certainly so. I wouldn't characterize the difficulty level as high - what it will do is quite interesting, but in the stages I'm at for now, it's by far not the most technically difficult thing I have worked on. But I have a lot to achieve with somewhat limited resources in the beginning, which makes the challenge more interesting. This reason is true of any other language: "where you have a lot of code in another language (especially non C, non Python) and defining an interface is not so easy;" True. But it doesn't matter for Java as you aren't going to be limited by libraries and if you're thinking about using Java it's something obvious to you. Whereas if you know nothing about D (and nobody in the audience had even downloaded DMD) then it's not (and it matters much more for D). And if you want to speak credibly, it's much better to be honest - if you got it, you don't need to make it flashy. I don't see that many talks on other emerging languages by proponents talking about the rough edges, and maybe that's because it's a bad idea, but maybe it's not. If I were being paid to sell D (a job I would never take if I could not speak about the rougher aspects) then it might be different - but it was a talk from a practitioner's perspective,
Re: good reasons not to use D?
On Wednesday, 4 November 2015 at 12:08:19 UTC, Laeeth Isharc wrote: this hardly matters for Java, C++, Python etc because mostly you won't need to use a bunch of different libraries. I meant mostly you won't need to go outside that ecosystem to use a bunch of different libraries whereas with D probably you will - and whilst it is not very difficult, writing it in D as a beginner or intermediate level programmer and calling a C library will take more time and effort than a guy of the same level doing the same in python (and I expect Go). Doesn't mean you shouldn't do it if you're going to use the library intensively - it's a price you pay once, and it might be small in the bigger picture - but if you are using a gazillion different libraries, each of which will need to be wrapped, you might want to think about whether D is the right tool for that task.
Re: good reasons not to use D?
On Wednesday, 4 November 2015 at 12:25:31 UTC, Laeeth Isharc 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. Sorry - I wrote this in a hurry, and I should have said on my experience of using D in finance (not the whole sector, which is absolutely enormous and very diverse), and what lessons and general things might be useful for others considering D. I can imagine lack of fixed point might be a problem. Shouldn't this be in Phobos? If BigInt is, then why not fixed point? There is this library here - had some problems compiling it last time (dmd versions), but it seems at least somewhat thought-through: https://github.com/jaypha/fixed train system ought to be sufficient to make that point... This module is nice (except the fact that's using std.math.lround all over the place which is available only on Linux) but, as I thought, keeping just a scale is not enough for multiplication or division: Fixed!4 a = "1_000_000_000_000."; Fixed!4 b = "0.5000"; Fixed!4 c = "2."; writeln((a * b).asString) will output -53402322211.2865 writeln((a / c).asString) will output 38831398157.2612 That's because we have a multiplication overflow in both cases.
Re: good reasons not to use D?
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.3003
Agreed.
Suggest 'dec' type.
Example:
dec foo{15,3};
Means simple variable 'foo' can hold fifteen digits, last three
decimal places.
DLearner
Re: good reasons not to use D?
On Monday, 2 November 2015 at 17:09:41 UTC, Laeeth Isharc wrote: On Saturday, 31 October 2015 at 16:06:47 UTC, Russel Winder wrote: On Sat, 2015-10-31 at 15:41 +, tcak via Digitalmars-d-learn wrote: [...] 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). I am Big Proponent of decimal arithmetic. It should be a breeze for a some of the smart folks using D. :):)
Re: good reasons not to use D?
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote: Interesting. Two points suggest that you should use D only for serious programming: "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" - quick and dirty "where you have many inexperienced programmers and they need to be productive very quickly." - quick and awkward [what does this tell us about financial programming ...] This reason is true of any other language: "where you have a lot of code in another language (especially non C, non Python) and defining an interface is not so easy;" In fact, the reasons you give (apart from the point about GUI) are true of C++, C#, Java etc. too. It's a bit generic. I was thinking of D specific reasons like lack of support for mobile platforms (not 100% yet). So your average stock broker couldn't calculate some bogus numbers on his iPad while having a latte and a Pelegrino in a posh cafe off Wallstreet. He he he. GC and lack of mobile are real reasons not to use D.
Re: good reasons not to use D?
On Saturday, 31 October 2015 at 16:06:47 UTC, Russel Winder wrote: On Sat, 2015-10-31 at 15:41 +, 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.3003 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).
Re: good reasons not to use D?
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?
Re: good reasons not to use D?
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.
Re: good reasons not to use D?
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.
Re: good reasons not to use D?
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
Re: good reasons not to use D?
On Sat, 2015-10-31 at 20:55 +, 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: good reasons not to use D?
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.
Re: good reasons not to use D?
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.
Re: good reasons not to use D?
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.3003 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.
Re: good reasons not to use D?
On Sat, 2015-10-31 at 15:41 +, 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.3003 > > 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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: good reasons not to use D?
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
Re: good reasons not to use D?
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
Re: good reasons not to use D?
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.3003
Re: good reasons not to use D?
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.3003 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.
Re: good reasons not to use D?
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.
Re: good reasons not to use D?
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
Re: good reasons not to use D?
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.3003 Isn't D used by a rather large banking company internally? I believe I remember this being mentioned somewhere.
Re: good reasons not to use D?
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.
good reasons not to use D?
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?
Re: good reasons not to use D?
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.
