Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

sebastianraschka.com

Post reply on HN
Print view View original

91–98 of 98 posts

Re: Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

#91

Post by GFK_of_xmaspast »

sgt101 wrote: post #65
GFK_of_xmaspast wrote: post #6

Earlier quoted context omitted.

One of the hats I wear is 'does numerics in python'. R is fine when you're playing to its strengths, matlab is an abomination, and I have absolutely no interest in julia.

Why no interest? If it is something that could make you more productive and make your life better then shouldn't you take an interest? Or do you mean "I have looked closely at Julia and it's no good because..." If so the because bit will be of interest to the Julia community (it's 0.4 now so lots of distance to go in its development before it becomes stable)

I took a look at Julia a couple years ago. As far as I could see, the only reason to consider it over python is the speed improvements, and if I'm in a situation where python isn't fast enough, I've already got c, c++, and java to reach for. (Also at the time the library support was lacking (I just checked and the graphs package, which I needed at the time, is still pretty minimal)).

Re: Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

#92

Post by GFK_of_xmaspast »

rm999 wrote: post #7

I switched from mostly using R to Python about a year ago for gluing together my data pipeline (from data source all the way to production models and frontends/visualizations). It hasn't really impacted what I'm capable of doing or my productivity, except the standard extra googling that comes in the first couple years I use any language. The main reason I went for Python is purely practical: it's a language people o…

I've been interviewing candidates recently and 'I just prototype in matlab and throw it over the wall to the implementation team' is a big negative in my evaluations (we don't have a wall in this company and I will fight to keep it that way).

Re: Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

#93

Post by leni536 »

tdees40 wrote: post #87
leni536 wrote: post #42

And there is nothing wrong with C++. For linear algebra I use the armadillo library and it's really a nice wrapper around LAPACK and BLAS (and fast!). For some reason scientists are somewhat afraid of C++. For some reason you "have to" prototype in an "easier" language. Sure, you can't use C++ as a calculator as opposed to interpreted languages, but I see people being stuck with their computations at the prototyping…

It's unimaginable for me to do most of this stuff without a REPL. That's the show-stopper for me with C++.

Maybe there will be a working REPL for C++ in the future:

https://github.com/vgvassilev/cling

Re: Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

#94

Post by dnautics »

rasbt wrote: post #10
idunning wrote: post #5

As someone who almost exclusively uses Julia for their day-to-day work (and side projects), I think most of the author's thoughts about Julia are correct. I think the language is great, and using it makes my life better. There are some packages that are actually better than any of their equivalents in other languages, in my opinion. On the other hand, I've also got a higher tolerance for things not being perfect, I c…

Thanks for the comment (I am the author of this article). > I have a feeling the author will find their way to Julia-land eventually, in a couple of years or so. I have a strong feeling that this will eventually happen :). In an ideal, less busy, world, I would love to use Julia alongside to explore and battle-test it further. Or even develop useful packages, libraries, and functions for it. The truth is, I am curren…

I think that the popularity of julia is exploding (but I'm biased - am writing an... interesting library for julia right now).

"There is really nothing wrong with R"

I think there is one thing wrong with R - it's name. Pretty much impossible to quickly google for help on it.

Re: Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

#95

Post by xixi77 »

thanatropism wrote: post #23

One thing missing here: Matlab syntax is actually very close to modern Fortran. At least twice I've written Fortran code (for Monte Carlo simulations; different contexts) by overwriting Matlab code adding types / general verbosity / fixing the syntax of do-loops / etc.

This is a very good point actually, I have done the same a few times. Of course this works well until you get to code heavily dependent on toolbox functions.

Which leads to another advantage of Matlab (at least as long as you don't have to pay for it) -- the documentation (including toolbox documentation) is way ahead of any competition.

Whoever came up with the R package documentation standard has done that language a great disservice :( IMO, the fact that every R package includes a huge pdf with alphabetical listing of functions and data sets is actively harmful: without it, perhaps more package authors would at least feel compelled to write a 2-page readme.txt (just like various matlab package writers do), and that would have been actually useful.

Re: Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

#96

Post by justthistime_ »

drauh wrote: post #58
rm999 wrote: post #7

I switched from mostly using R to Python about a year ago for gluing together my data pipeline (from data source all the way to production models and frontends/visualizations). It hasn't really impacted what I'm capable of doing or my productivity, except the standard extra googling that comes in the first couple years I use any language. The main reason I went for Python is purely practical: it's a language people o…

Yeah, there is a large community of Python users in scientific computing. It's great. I like well-established languages with a large user base. So, I was dismayed by Big Data Genomics' ADAM Project's choice of Scala, which has almost no uptake in the genomics/bioinformatics community. They do it because they run over Spark. But Spark has an excellent Python binding.

Python's days have come and gone.

Computation has grown more complicated. They need real computer scientists and a real language that supports real development, not some scientists which learned just enough Python to automate running some 20 year old Fortran code.

Re: Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

#97

Post by Lofkin »

justthistime_ wrote: post #96
drauh wrote: post #58

Earlier quoted context omitted.

Yeah, there is a large community of Python users in scientific computing. It's great. I like well-established languages with a large user base. So, I was dismayed by Big Data Genomics' ADAM Project's choice of Scala, which has almost no uptake in the genomics/bioinformatics community. They do it because they run over Spark. But Spark has an excellent Python binding.

Python's days have come and gone. Computation has grown more complicated. They need real computer scientists and a real language that supports real development, not some scientists which learned just enough Python to automate running some 20 year old Fortran code.

So Julia then :)

Re: Python, Machine Learning, and Language Wars. A Highly Subjective Point of View

#98

Post by TheBlackCat13 »

sampo wrote: post #40
jacobolus wrote: post #24

Earlier quoted context omitted.

Interesting. In my own experience trying to implement the same image processing algorithms in Matlab vs. numpy, the work took about the same amount of effort any time arrays were limited to 1-2 dimensions, all the code was simple numerical stuff, and it wasn’t necessary to break the code up into multiple functions. The Matlab one-file-per-function thing, the lack of namespaces, and general lack of code structuring pr…

I would imagine, for a beginner, in Python the difference between a list and a numpy array can be confusing. And in numpy, column vectors and row vectors are a different thing. Whereas in Octave/Matlab "everything just works" in the do-what-I-mean sense. > The Matlab one-file-per-function thing By the way, Octave does not have that limitation.

> And in numpy, column vectors and row vectors are a different thing. Whereas in Octave/Matlab "everything just works" in the do-what-I-mean sense.

I think this is actually one of MATLAB's biggest flaws. Without a true 1D array like numpy has, there is no way in MATLAB to tell the difference between a 1D sequence of values, and a 2D sequence of values with only one value along one of the dimensions.

This has led function developers to try to guess. But they guess inconsistently. Some functions treat row and column vectors differently, some treat them the same. Of those that treat them the same, some return them with the same orientation, while other force a particular orientation. Some operations ignore dimensions (length), others don't (for loops). Some maintain dimensions (size), some don't ([:]).

So everything may seem to work, until your code that has been working fine for years suddenly breaks, and you realize it is choking up because one of your experiments has only one trial, or one of your experiments has multiple trials each with one result, and some of the functions you are using start reacting differently to this. Then you have to go through each function and figure out on a case-by-case basis how it handles row and column vectors.

Or worse yet, it seems to run fine, but is silently doing the wrong thing. Which you probably would never know, because most MATLAB code isn't unit-tested.

Post reply on HN