This is all fascinating stuff, I've learned a lot. If this is the outcome of recruiters posting on the list, I'm all for it!
On Wed, Dec 15, 2010 at 11:02 PM, Andy Robinson <a...@reportlab.com> wrote: > > Report Lab does a fair bit of work in the financial sector in a rather > different field. > Sorry, the light took a while to reach the batcave tonight... > > I was pushing Python in finance back in 1997/8, and there have been > many, many people using it (usually under the radar at first) in the > City for a long time. In the old days it excelled at gluing systems > together, scripting other peoples' C code, and prototyping algorithms. > There were many times when people needed a solution faster than "IT" > could organise it, and being freely available and able to work with > Excel, it helped a lot of quants. > > Now, of course, Python is mainstream, and other languages have got a > lot better at the 'glue' and web stuff and caught up to some degree. > > > On 15 December 2010 14:02, Jonathan Hartley <tart...@tartley.com> wrote: > > On the other hand, if you're running across the > > internet, then any slowdown due to using Python verses another language > > would be vastly swamped by network and other IO delays. Am I very much > > mistaken? > > There are no general answers to that question. There are indeed many > cases where people needlessly worry about the language when network > and IO dominate. There are also lots of cases where you want to do > some kind of "atomic job" on one machine, and find it's an order of > magnitude too slow in a high level language. There are some "Monte > Carlo" approaches to pricing securities which have no analytic > solution; and in the retail sector it's fashionable now to show > 'clouds of outcomes' about where your pension might end up, needing > 10000 random walks to plot a chart and spit out a 2-3 page PDF > including it. > > Two of the beauties of Python in this area are that (a) you can afford > to rewrite your algorithm several times and be sure it's the best > approach, and (b) if you really need to, it's easy to shift the 'inner > loops' into C. > > Putting it in perspective, I even know some people in the City who > find hand-coded C too slow for their simulations, and who are > basically writing microcode for chips in order to put a supercomputer > under their desk! > > The bigger question is whether all this horsepower ultimately leads to > better investment performance. I will stay out of that one ;-) > > > -- > Andy Robinson > ReportLab > _______________________________________________ > python-uk mailing list > python-uk@python.org > http://mail.python.org/mailman/listinfo/python-uk >
_______________________________________________ python-uk mailing list python-uk@python.org http://mail.python.org/mailman/listinfo/python-uk
