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 +0000, 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. :):)

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

Agreed.

Suggest 'dec' type.

Example:
dec foo{15,3};

Means simple variable 'foo' can hold fifteen digits, last three decimal places.

DLearner

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.

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, one who deeply appreciates the language and the community, but not a fanatic.

I've been sold to a lot in the years, and I find people who are honest with me about the problems are much more convincing.  Depends on your target market, but the natural D demographic isn't going to be easily fooled anyway, so it's one of those nice occasions where doing the right thing has no cost.

> 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

Really?  I think yes abstractly "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" is true of many languages.  But practically speaking (and I'm acting for now as a merchant, albeit one with an aesthetic, non-mercantile appreciation) this hardly matters for Java, C++, Python etc because mostly you won't need to use a bunch of different libraries.

Porting and wrapping things has definitely cost me some time, but I don't mind too much because I learnt a lot by doing so, and because it's a one-off cost that's small in the context of my bigger goal.  Had I gone a more enterprisey route, I'd be paying a higher price via different means (lower share of the pie, and much more friction, wasted time in meetings, and frustration).

And if you have inexperienced programmers (and I tried working with one as I was getting started recently, and then before that at my fund) then with Python or Go it will go much more quickly and easily than with D - because of the language, the docs, and the 'diversity' of the community (D caters less in its ecosystem to beginners, except in the helpfulness of people in the forums, which is quite a lot, but not enough to offset the other things).

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

I wouldn't include that in a talk as anyone who comes is not likely to be open to using D primarily for mobile platforms.  Like if that's the deal-killer, why would he come?  And my guess - without knowing much - is that this is a matter of a little time, and in a year or two it will be good enough to write some basic apps.

BTW financial people may not be quite as your image of them might be.  On the hedge fund side there is an inordinate number of exceptionally smart people.  My old boss came top in his year in maths at Cambridge, and when I asked his Directory of Studies where I could find another chap of his ability amongst recent graduates, he laughed and said a man like that comes along only every few years if you are lucky.  He's now a machine learning researcher back at Cambridge.  And there are many others like him, or perhaps even smarter, that you never hear about.  Michael Hintze is one that has a public profile.

A chap I worked with 20 years back linkedin me to thank me for my posts on D.  He was a pretty successful trader that ended up setting up a market-making business, but even a few years in he felt a degree of mental pain financially.  Because he had turned down a personal offer from Bill Gates to work with him (they didn't hire dummies, certainly then), and the stock from his signing on bonus would have been worth $20mm.  He's for now less interested in programming as he is learning Greek to take advantage of opportunities there.

There are even many smart stockbrokers (although it's been a less cerebral job) because the collapse in commissions amidst a lower-volume environment has been brutal and best execution means the old relationship stuff is rather different.  So to survive you have to be a different kind of person than the guys that flourished before.

> GC and lack of mobile are real reasons not to use D.

Depends what you are trying to do!  If you aren't writing mobile apps (as I'm not on a horizon that matters for planning) and don't care about latency there are still many questions to think about.  I've had to think about this from another perspective lately, as I need to see whether it makes sense for my client to consider starting to use D inside the organization in some ways, and I'm not going to last very long and it wouldn't be the right thing to do if I suggested he should use D just because I happen to like it..

BTW if you would like to chat about natural language processing, please drop me a line by email.


Laeeth.

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.

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

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.0000";
Fixed!4 b = "0.5000";
Fixed!4 c = "2.0000";

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.

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