Live data from Hacker News

Introduction to Python for Computational Science and Engineering [pdf]

southampton.ac.uk

21–30 of 55 posts

Re: Introduction to Python for Computational Science and Engineering [pdf]

#21
post #19

I'm very sympathetic to "use python2." I still use python2. But we should all keep in mind the "no shit really this time" EOL for python is 2020. http://legacy.python.org/dev/peps/pep-0373/ Even if you say "well, it'll just be forked," you don't really know how many forks and pain there will be. Maybe python2 will be like LibreOffice, or maybe it will be like OpenOffice. Like it or not, python3 is the future.

And the bucket of people who want python2 forked weighed against the bucket of people can can fork/maintain it are not equal.

Re: Introduction to Python for Computational Science and Engineering [pdf]

#22
post #6
post #4

> As Python 2.x is still the default Python on many system and there are a fair number of research codes out there based on Python 2, we will use Python 2.x in this book. This is so unfortunate. Scientific computing is riddled with technical debt and starting with Python 2 today is fairly irresponsible. If you're already invested in Python 2 and have code/training written up, fine. But if you're learning it just now,…

I'd be happy to hear examples how Python 3 helps us in computational sciences. I've barely even tried it before and have used Python 2 a lot.

> I'd be happy to hear examples how Python 3 helps us in computational sciences

Sir/Madam, I am here to make you happy then. Python 3's multiprocessing library is leaps and bounds "better" than python 2's. By "better", I mean faster(in my workloads) by 30-40%. If time is money, then that feature alone saves you both.

Re: Introduction to Python for Computational Science and Engineering [pdf]

#25
post #4

> As Python 2.x is still the default Python on many system and there are a fair number of research codes out there based on Python 2, we will use Python 2.x in this book. This is so unfortunate. Scientific computing is riddled with technical debt and starting with Python 2 today is fairly irresponsible. If you're already invested in Python 2 and have code/training written up, fine. But if you're learning it just now,…

This was an introduction to Python. I went through every example while reading this book and rarely found a point where translating to python 3 was any trouble.

Re: Introduction to Python for Computational Science and Engineering [pdf]

#26
I just finished working through this book and I really enjoyed it. I went from next to no Python knowledge to writing programs to analyze raw vibration data in a few days. I had previous experience with Matlab and this book was very useful in bridging the gap between the two systems.

Re: Introduction to Python for Computational Science and Engineering [pdf]

#27
post #6
post #4

> As Python 2.x is still the default Python on many system and there are a fair number of research codes out there based on Python 2, we will use Python 2.x in this book. This is so unfortunate. Scientific computing is riddled with technical debt and starting with Python 2 today is fairly irresponsible. If you're already invested in Python 2 and have code/training written up, fine. But if you're learning it just now,…

I'd be happy to hear examples how Python 3 helps us in computational sciences. I've barely even tried it before and have used Python 2 a lot.

The new matrix multiplication operator in 3.5 is nice syntactic sugar:

  C = A@B
vs

  C = A.dot(B)

Re: Introduction to Python for Computational Science and Engineering [pdf]

#28

Earlier quoted context omitted.

I actually see np.dot(np.dot(x,y),z) as easier to read and remember. It is more explicit in what it is doing. Being explicit is a good thing.

a + 4*(x-y) + b**5 vs (+ a (* 4 (- x y )) (expt b 5 )) Sometimes, as arithmetic with lisp shows, conciseness is better. Also, it isn't being more explicit than it is being more verbose .

It is abosolutely being more explicit. It's being more explicit that (expt b 5) is a unit that forms a single argument in the + form.

This is implicit in

  a + b ** 5
according to a precedence rule between the and + operator, which is hidden in the parser's implementation and in documentation thereof.

Well, the white-spacing

  a + b**5
suggests it. But the suggestions produced by insignificant whitespace can be mere wishful thinking:

  int* x, y; // two C pointers? not!
Speaking of whitespace, also have the advantage of there being multiple ways to split the expression into multiple lines, all conforming to a very clear, simple formatting rule:

  (+ a
     (* 4 (- x y))
     (expt b 5))

  (+ a
     (* 4
        (- x y))
     (expt b 5))
Fully expanded, every term on separate line:

  (+ a
     (* 4
        (- x
           y))
     (expt b
           5))
In this manner, we can write complex expressions that would be quite unreadable in infix, requiring break-up into intermediate temporaries.

We almost have a circuit diagram now with "gates" for the operations: a three input + gate, etc:

     ____
    /    |- a
    |    |      ____
  --| +  |-----/    |- 4
    |    |     |  * |      ____
    \____|-    |    |-----/    |- x
           `   \____|     | -  |
            |             \____|- y
            |   _____     
            `--/     |- b
               | expt|
               \_____|- 5

Re: Introduction to Python for Computational Science and Engineering [pdf]

#29
post #4

> As Python 2.x is still the default Python on many system and there are a fair number of research codes out there based on Python 2, we will use Python 2.x in this book. This is so unfortunate. Scientific computing is riddled with technical debt and starting with Python 2 today is fairly irresponsible. If you're already invested in Python 2 and have code/training written up, fine. But if you're learning it just now,…

The assertion is also not necessarily accurate. Python 2 & 3 are included on Ubuntu 14.04 (and maybe earlier). My understanding is that different system tools require different versions.

Python 2 is /usr/bin/python Python 3 is /usr/bin/python

If on Windows and you have both python 2.7 and python 3.x installed, just just use the py command to automatically select the correct runtime. I think you may need to specify the shabang for this to work (i.e. "#!/usr/bin/env python" for a 2.x script and "#!/usr/bin/env python3" for a 3.x script).

Despite some recent discussions lamenting slow adoptions, everyone I know and myself write all new code in 3.5.x and only fall back to 2.7 for legacy code or when you need a module that is not yet 3.x compatible. Problem is I work at a small company with about 10 devs. If a 2.x script works, we have zero incentive to port it to 3.x because we have such a huge backlog of work items.

Re: Introduction to Python for Computational Science and Engineering [pdf]

#30
post #5

Earlier quoted context omitted.

I'm a hardcore proponent of Python 3 (because it's the only Python I've ever used/learned), but I'm OK with this book accepting the realities and for at least committing to writing 3.x compatible code: > However, we will write code that is as much as possible in the Python 3 style (and understood by Python 2). The most prominent example is that in Python 2.x, the print command is special where as in Python 3 it is an…

Reduce is easy to fix also, but that ignores the entire reasoning for it being removed and only serves to highlight the massive chasm between 2 and 3. The clean break of 3 and the sanity it brings to the language is undeniable.

> The clean break of 3 and the sanity it brings to the language is undeniable.

Well, I can't deny they broke it, but sanity is pretty deniable. Python has always been a dynamic language, and one of the core mantras was "there should be one obvious way to do it" (in contrast to Perl). All the new type annotation stuff and the multiple ways to handle string formatting are steps in very weird directions. Maybe they should make a Python version 4 to clean some of that mess up.

Post reply on HN