Live data from Hacker News

Introduction to Python for Computational Science and Engineering [pdf]

southampton.ac.uk

31–40 of 55 posts

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

#31
post #8
post #6

Earlier quoted context omitted.

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.

It's not that it helps in a particular way (though more on that below), it's just that starting with Python 2 now necessarily leads to rewrites later on. While you can see packages not supporting Python 3 (there are fewer and fewer of those), in the future you will see the opposite, some project already announcing end dates for their Py2 support (IPython to give an example). I have to stress that I used 2to3 to tackl…

> It's not that it helps in a particular way (though more on that below), it's just that starting with Python 2 now necessarily leads to rewrites later on. While you can see packages not supporting Python 3 (there are fewer and fewer of those), in the future you will see the opposite, some project already announcing end dates for their Py2 support (IPython to give an example).

So, there's no benefit to Python 3, but we should all migrate to it anyways? You think Python 2.7 will die, but trust me as soon as the PSF abandons it, someone will swoop in and become the new defacto supporter. For many of us, stability is a feature, and the fact that 2.7 won't change in gratuitous ways is super attractive.

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

#32
post #6

Earlier quoted context omitted.

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.

If you really want to run faster, you should try a new language. 30-40% for multiprocessing is nowhere near the benefit you'd get from a single threaded implementation in C, C++, Java, Rust, Ocaml, Go, or even JavaScript or LuaJIT. Those runs between 10 and 1000 times faster (1000% - 100000%) than Python.

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

#33
post #27
post #6

Earlier quoted context omitted.

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)

This is the only compelling reason I've seen to switch to Python 3.

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

#34
post #8

Earlier quoted context omitted.

It's not that it helps in a particular way (though more on that below), it's just that starting with Python 2 now necessarily leads to rewrites later on. While you can see packages not supporting Python 3 (there are fewer and fewer of those), in the future you will see the opposite, some project already announcing end dates for their Py2 support (IPython to give an example). I have to stress that I used 2to3 to tackl…

> It's not that it helps in a particular way (though more on that below), it's just that starting with Python 2 now necessarily leads to rewrites later on. While you can see packages not supporting Python 3 (there are fewer and fewer of those), in the future you will see the opposite, some project already announcing end dates for their Py2 support (IPython to give an example). So, there's no benefit to Python 3, but…

exactly. This is what i have always believed. just Google and Dropbox have too much py2 code to drop it or do a wholesale conversion.

Nothing is going to be EOLed. Its going to be business as usual and the python foundation will never agree to killing python 2 in the next decade.

the only way forward is through six ( https://pypi.python.org/pypi/six) or something like it. Its well worth building and funding a python 2 compatibility layer in python3... and then moving to py3 runtime.

im actually surprised that someone like Google is not throwing some funding towards building a compatibility layer.

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

#35
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,…

IMO, Python 3's support for matrix multiplication using the @ operator is itself worth the cost of admission. Much of technical computing is just implementing algorithms that use linear algebra extensively, and if you're coming from matlab littering your code with dot(dot(X,Y),Z) is a real pain

everyone i know does matrix multiplication using numpy or pandas and conveniently abstracts away the need to do language conversion.

same thing with asyncio vs gevent and tons of otger features. I say this again - there are industrial strength packages and libraries for py2 that gives all the power and convenience that you think you get in py3. Perhaps even better tested and used in production.

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

#36

Earlier quoted context omitted.

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 shou…

>new type annotation stuff

xrange is now range?

>multiple ways to handle string formatting

This is a problem?

As for sanity: bytes/unicode integer division chained exceptions os.scandir performance

I'm keen for 4 when it comes. Clinging to the past is only going to make things harder.

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

#37

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.

That's great. Have you been writing vectorized code in Python then?

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

#38
post #18

Earlier quoted context omitted.

In a lot of scientific computing backwards compatibility is essential. Knowing Fortran in that world is still helpful, even if you only have a basic understanding it helps with common packages like LAPACK and ARPACK. In science the science is first and coding second. Coding is just the tool used to get the job done. Most people in the community adopted python2 because it was easier to use than C/Fortran in a lot of c…

I very much understand the bit that science is first and code second. I live by the very much same principle at work and we actually have a lot of (terrible) Fortran and C/C++ code around. And we're trying to adopt Python for large parts of of it. But I'm not sure I follow your argument. I'm not talking about rewriting existing code. I'm talking about building new things. And they should be built in Python 3, because…

Well I guess the point of my argument boils down to the problem of changing key functions in established code. Even Fortran when they adopted new standards, old stuff works fine, for the most part. The problem with python is more that it got really popular in the scientific community, because it is relatively fast and extremely easy to write in, but some of the packages were slow to adopt. I think this created a weird scenario where I'm not sure if python2 will ever go away. The scientific world fell in love with python because it was like a free MATLAB, but more useful. And by the time 3 came out there was a lot of code developed that wouldn't port. If we get down to it, I think this is more a problem of porting than anything else. The scientific community has already made headway into 2 and I will admit that we are really slow to adopt. Because of this I think 2 will stay for quite some time. Myself, I don't take the time to learn 3 because if I write in it I'd just confuse my team. I literally can't write in 3 because it'd be detrimental to my job. This is definitely true for a lot of the scientific computing world. There is always an inherent danger to adopting new standards to a language. And python shows where it can turn bad. Because it got really popular and even though it isn't that detrimental to normal python users it is a huge difference in the scientific world.

I will mention that as a more middle ground coder and physicist, scientists are horrible programmers. Horrible. In python I don't see a lot of uses of definitions, so there are A LOT of global calls. I don't think I'm a great programmer, but it is definitely a focus on "programming is a tool" in our sphere. So there is no real care about "future proof" or any of that. The real care, especially in academia, is "can I get this done". Really the only people that care about future proof are the national labs that are building libraries to be used in mass, something like PETSc. But you even get problems there because things like ARPACK have issues, because it is dependent upon LAPACAK (many might not know, but there is a compatibility issue there with the newest versions).

I myself get upset about this. But what are you going to do? I don't disagree with the science first coding second attitude. But there needs to be a conscious effort of making things, at least, more future proof. The problem is no one pays us for that. We get paid for results. We do not get paid for verification, mind you that is an EXTREMELY important part of science. And we don't, usually, get paid for software development, at least primarily (we do if it leads to results). So it is convoluted and this turns into a large argument about a lot of things. But it is nowhere near as simple as "python 3 is supposed to be the new standard therefore we should write in it." Being a tool, we will always work off of previous code base, and we will always learn what the writer (or HOPEFULLY someone that knows a semblance of what the code does) tries to do with the code/library.

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

#39
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.

Why do you think `reduce` was moved to functools?

As far as I know, it was simply because few people used it correctly and Guido thought it would help to tuck it out of the way in a module. That doesn't feel like a massive chasm to me. Most of the 2/3 moves and renames were cosmetic.

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

#40

Earlier quoted context omitted.

> 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.

If you really want to run faster, you should try a new language. 30-40% for multiprocessing is nowhere near the benefit you'd get from a single threaded implementation in C, C++, Java, Rust, Ocaml, Go, or even JavaScript or LuaJIT. Those runs between 10 and 1000 times faster (1000% - 100000%) than Python.

Those runs between 10 and 1000 times faster (1000% - 100000%) than Python.

They're faster than pure python in the general case, but once you throw numpy, numba, numexpr and cython into the mix and focus on numeric workloads, most of that difference disappears.

Post reply on HN