Python / Visual Basic mathematical comparison
Travis Oliphant
olipt at mayo.edu
Wed May 24 09:57:59 EDT 2000
> I have been programming in both (although I stopped with VB after I
> discovered Python:-), so here is a short summary.
>
> If we look at the bare facts we have:
>
> Py VB
> Int*2 N Y
> Int*4 Y[1] Y
> Long[2] Y N
> Real*4 N Y
> Real*8 Y Y
> Currency N Y
>
> Array arith. Y[3] N[4]
>
> Callbacks Y[5] Y
> Modules Y Well, sort of
> Dynamic YES N
> Interactive Y Not very good
>
> 1: Can be Int*8 on 64 bit machines
> 2: Long is abitary precision integer values
> 3: Through NumPy
> 4: Not that I know of
> 5: From within python only
Thanks for this comparison. A couple of things are not stated, however:
Types:
Through NumPy you have Int*2, and Real*4. Several people have posted
example currency classes.
Callbacks:
I don't understand what you mean by "From within Python only." You can
callback into Python from C-code and vice-versa, so I'm not sure what you
were trying to communicate with this restriction.
> 5) The speed issue is difficult:
> a) If you run lots of matrix math you can use NumPy, and it is
> *fast*. There is no alternative to NumPy in VB (to my knowledge)
You can use NumPy for lots of things besides just "matrix" math. You can
store large amounts of data in a small space and do rapid operations on
that data as well. As a result, image processing can be done very well
using the NumPy object.
> The question you need to ask yourselves on speed is "how fast is fast
> enough". At present Python is (unfortunatly) not fast enough for our
> line of work (real time calculation of large ODE's),
Have you tried multipack? It contains a module that links the
FORTRAN integration routines in ODEPACK. It is rather fast, but because
it calls a Python function at each step it is not "as fast as machinely
possible." Still, a combination of Python/(C,FORTRAN) is very fast.
-Travis
More information about the Python-list
mailing list