Fortran (Was: The "does Python have variables?" debate)

Alain Ketterlin alain at dpt-info.u-strasbg.fr
Mon May 12 04:44:42 EDT 2014


Mark H Harris <harrismh777 at gmail.com> writes:

> On 5/11/14 12:05 PM, Alain Ketterlin wrote:
>>> Julia is Matlab and  R, Python, Lisp, Scheme; all rolled together on
>>> steroids. Its amazing as a dynamic language, and its fast, like
>>> lightning fast as well as multiprocessing (parallel processing) at its
>>> core. Its astounding, really.
>>
>> Hmmm...
>>
>>> Its number concept is unified,
>>
>> What exactly is unified? There is no implicit promotion between
>> primitive types and BigInt/Float.
>
>
> The built-in math functions (extensive, by the way) just work, and
> they work consistently the way you might expect across types. Consider
> sqrt():
[...]
> You'll notice that I did not need to import anything to use sqrt(),
> and sqrt() takes all types and does something meaningful with them.

Sorry, i wasn't clear enough: "doing something meaningful with them" is
precisely where the problem is. Every single operation requires
multiple-dispatch (i.e., dynamically testing types, converting to a
common type, and selecting the version of sqrt to use). That's probably
more than the time it takes to actually perform the computation, a bit
like what happens with x+y on integers with Python, where only a
fraction of time is spent on adding integers.

When you are doing scientific computation, this overhead is
unacceptable, because you'll have zillions of computations to perform.

Julia provides a way to make things fast: typing. If you provide
explicit types, the dynamic typing part obviously disappears, and
the overhead is removed.

But then, you're not too far from Fortran, or C/C++.

> The following code will produce over 100,000 digits of π (pi) in less
> than 2 seconds on a low-end processor, like my mac mini dual core
> 2Ghz:

You seem to be discovering the power of the libraries that are behind
all this (MPFR in that case)...

[...]
> But, like lisp, Julia's internal structures are lists, so, it can
> create and modify its own code on-the-fly. [...]

Sorry, I was comparing to Fortran, and it's use in scientific computing.
Self modifying code is totally irrelevant there.

-- Alain.



More information about the Python-list mailing list