[python-uk] London Python Roles

[Robin Shields]

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
> ReportLab
> _______________________________________________
> python-uk mailing list
> python-uk at python.org
> http://mail.python.org/mailman/listinfo/python-uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-uk/attachments/20101216/7e547813/attachment.html>