[python-uk] London Python Roles
robinshields at gmail.com
Thu Dec 16 12:10:06 CET 2010
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 <andy at 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 <tartley at 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
> python-uk mailing list
> python-uk at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the python-uk