On Tuesday, 23 December 2014 at 03:07:10 UTC, Laeeth Isharc wrote:
> At one very big US hf I worked with, the tools were initially written in Perl (some years back).  They weren't pretty, but they worked, and were fast and robust enough.  I has many new features I needed for my trading strategy.  But the owner - who liked to read about ideas on the internet - came to the conclusion that Perl was not institutional quality and that we should therefore cease new development and rewrite everything in C++.  Two years later a new guy took over the larger group, and one way or the other everyone left.  I never got my new tools, and that certainly didn't help on the investment front.  After he left a year after that they scrapped the entire code base and bought Murex as nobody could understand what they had.
>
> If we had had D then, its possible the outcome might have been different.
>

Interesting perspective on the FI group's use of perl. Yes that group was one of the reasons a whole new architecture committee was established to prevent IT tool selection (like Perl and especially Java) the firm did not want to be used or supported. Imagine after that being prohibited from using Python. Having to beg to get to use it embedded from C++ and when finally granted permission having to rewrite the much of boost python since boost was not a sanctioned tool. Big companies make decisions differently than others. I believe D would not have been a help in that organization and requesting its use would have been the surest way to get a termination package. That said, in other organizations D might have been a good choice.

> So in any case, hard to generalise, and better to pick a few sympathetic people that see in D a possible solution to their pain, and use patterns will emerge organically out of that.  I am happy to help where I can, and that is somewhat my own perspective - maybe D can help me solve my pain of tools not up to scratch because good investment tool design requires investment and technology skills to be combined in one person whereas each of these two are rare found on their own.  (D makes a vast project closer to brave than foolhardy),
>
> It would certainly be nice to have matrices, but I also don't think it would be right to say D is dead in water here because it is so far behind.  It also seems like the cost of writing such a library is v small vs possible benefit.
>

I did not say D is dead in the water here. But when it comes to math platforms it helps to have lots of people behind the solution. For math julia seems to have that momentum now. Maybe you can foster that in D.

On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder wrote:
> On Sat, 2014-03-22 at 00:14 +0000, Daniel Davidson wrote:
> […]
>> Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately.
>
> I would certainly agree that (at least initially) pitching D against the Excel/Python/R/Julia/Mathematica is an easier fight. The question is how to convince someone to take the first step.

In that case, a good start might be a D kernel for IPython/Jupyter. Seeing an interactive D REPL session inside a notebook should make a pretty convincing demo.

On Tuesday, 23 December 2014 at 07:51:18 UTC, Oren Tirosh wrote:
> On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder wrote:
>> On Sat, 2014-03-22 at 00:14 +0000, Daniel Davidson wrote:
>> […]
>>> Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately.
>>
>> I would certainly agree that (at least initially) pitching D against the Excel/Python/R/Julia/Mathematica is an easier fight. The question is how to convince someone to take the first step.
>
> In that case, a good start might be a D kernel for IPython/Jupyter. Seeing an interactive D REPL session inside a notebook should make a pretty convincing demo.

That's an interesting idea, how would you approach it though with a compiled non-functional language? Maybe in the same way the %%cython magic is done?

On Tuesday, 23 December 2014 at 13:28:22 UTC, aldanor wrote:
> On Tuesday, 23 December 2014 at 07:51:18 UTC, Oren Tirosh wrote:
>> On Saturday, 22 March 2014 at 12:06:37 UTC, Russel Winder wrote:
>>> On Sat, 2014-03-22 at 00:14 +0000, Daniel Davidson wrote:
>>> […]
>>>> Maybe a good starting point would be to port some of QuantLib and see how the performance compares. In High Frequency Trading I think D would be a tough sell, unfortunately.
>>>
>>> I would certainly agree that (at least initially) pitching D against the Excel/Python/R/Julia/Mathematica is an easier fight. The question is how to convince someone to take the first step.
>>
>> In that case, a good start might be a D kernel for IPython/Jupyter. Seeing an interactive D REPL session inside a notebook should make a pretty convincing demo.
>
> That's an interesting idea, how would you approach it though with a compiled non-functional language? Maybe in the same way the %%cython magic is done?

I think the trick used by http://drepl.dawg.eu is to incrementally compile each command as a subclass of the previous one, link it as a shared object, load it and call a function.

On Monday, 22 December 2014 at 13:37:55 UTC, aldanor wrote:
...
>
> In this light, as I see it, D's main advantage is a high "runtime-efficiency / time-to-deploy" ratio (whereas one of the main disadvantages for practitioners would be the lack of standard tools for working with structured multidimensional data + linalg, something like numpy or pandas).
>
> Cheers.

There is no lack of tools if you can integrate well with existing ones like numpy, pandas, matplotlib, etc. I think a good role for D in such an ecosystem would be implementation of algorithms.

D's excellent template system can be leveraged to help it play well with dynamically typed languages. A D module to be called from Python may be kept in source form that is compiled and specialized on demand according to argument types and the dtypes and dimensions of numpy array arguments. Specific specializations will be cached so from the second call it will not incur the 1-2 second overhead of compilation. If you only use the @safe subset there should be no danger in dynamically compiling bits of code and loading them into the address space of your session.

On Tuesday, 23 December 2014 at 03:07:10 UTC, Laeeth Isharc wrote:
>
> It would certainly be nice to have matrices, but I also don't think it would be right to say D is dead in water here because it is so far behind.  It also seems like the cost of writing such a library is v small vs possible benefit.

I have a longer horizon than the HFT guys, but I still have quite a demand for high performance computing when backtesting a quantitative strategy. A backtest will typically involve
1) Put some data in a database
2) Apply statistical models to appropriate data
3) Create forecast distribution
4) Optimize portfolio given forecast
5) Repeat 2:4 in each period and calculate performance of strategy

The biggest limiting factor to implementing it in D is a mature math/stats library (I understand SciD is a thing, but I have not tried it). Most optimization packages are written in C and could probably be called in D (haven't tried, but I imagine). There's a mysql module for D, though I think python has much better options here (I have been pretty impressed with blaze). Python's Pandas is also pretty helpful, but as it is built upon numpy, something equivalent would need to built upon a matrix library in D.

I think it would also be helpful for bindings to Julia and C++ (so I can use MC Stan or Quantlib). I think the pyd project is pretty important. Might be good to write up an example using it for a finance application.

On Friday, 21 March 2014 at 21:14:15 UTC, TJB wrote:
> Walter,
>
> I see that you will be discussing "High Performance Code Using D" at the 2014 DConf. This will be a very welcomed topic for many of us.  I am a Finance Professor.  I currently teach and do research in computational finance.  Might I suggest that you include some finance (say Monte Carlo options pricing) examples?  If you can get the finance industry interested in D you might see a massive adoption of the language.  Many are desperate for an alternative to C++ in that space.
>
> Just a thought.
>
> Best,
>
> TJB

1+ for finance talk