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

61–70 of 98 posts

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

#61

Post by srean »

microtonal wrote: post #59
srean wrote: post #55

Earlier quoted context omitted.

> you can just pick the BLAS implementation that is the fastest on your platform and run with it Just in case this is useful info, Eigen and Blaze works the same way, Blitz++ doesn't. Blaze seems to be doing the best in the benchmarks. > OpenBLAS is pretty much on par with Intel MKL I wont be surprised. I have seen ATLAS beat MKL on some BLAS functions on my runs. Sparse matrix multiply is particularly badly implemen…

Just in case this is useful info, Eigen and Blaze works the same way, Blitz++ doesn't. I was under the impression that Eigen only works with MKL? Enables the use of external BLAS level 2 and 3 routines (currently works with Intel MKL only) Source: http://eigen.tuxfamily.org/dox/TopicUsingIntelMKL.html But the reason I mentioned ICC is that there is much more to SIMD than just linear algebraic operations. Indeed. I co…

Its a BLAS library standard API that you are linking to, so the vendor doesn't matter so much (in theory). In practice, the amount of annoyance that you have to go through so that it links correctly can vary a lot. Even MKL did not implement all of BLAS / Lapack and that would lead to some linking errors.

Re GCC, the same here. ICC is mighty expensive.

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

#62

Post by geomark »

RA_Fisher wrote: post #22
misiti3780 wrote: post #13

Octave/Matlab are "great" but good luck trying to integrate them into a production web application. Since you cant really do that - avoid using them unless you are fine with implementing the same algorithm twice. Matlab licenses cost money also, and the toolboxes cost additional money. R is useful because there are a lot of resources as it has been along for so long and is used by a large portion of the stats communi…

I'd like to kindly challenge the notion that you can't integrate R into a web application. I've started using R to power jobs that are used by a large web application. The R packages httr or RCurl make it pretty easy to make http requests -- (enabling me to send things to a web server to be consumed into a database and run by back-end code). It's also possible to prepare data in R and then send to a space like S3 wit…

I was just introduced to yhathq.com. It's a platform that allows you host your R function on the web and exposes an API. Seems quite interesting, and I'm wondering if it helps solve R-based web app problems.

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

#63

Post by microtonal »

srean wrote: post #61
microtonal wrote: post #59

Earlier quoted context omitted.

Just in case this is useful info, Eigen and Blaze works the same way, Blitz++ doesn't. I was under the impression that Eigen only works with MKL? Enables the use of external BLAS level 2 and 3 routines (currently works with Intel MKL only) Source: http://eigen.tuxfamily.org/dox/TopicUsingIntelMKL.html But the reason I mentioned ICC is that there is much more to SIMD than just linear algebraic operations. Indeed. I co…

Its a BLAS library standard API that you are linking to, so the vendor doesn't matter so much (in theory). In practice, the amount of annoyance that you have to go through so that it links correctly can vary a lot. Even MKL did not implement all of BLAS / Lapack and that would lead to some linking errors. Re GCC, the same here. ICC is mighty expensive.

I know that BLAS is a standard API, I switch between BLAS implementations fairly often :). I suspected that Eigen relied on some non-BLAS functions in MKL, since they explicitly state that only MKL works.

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

#64

Post by dalke »

a_bonobo wrote: post #39

>I think it [Perl] is still quite common in the bioinformatics field though!? That's true - many day-to-day tasks in bioinformatics are more or less plain-text parsing [1], and Perl excels in parsing text and quickly using regular expressions. "My" generation of bioinformaticians doing data cleanup and analysis (20-30) uses Python, sometimes because plotting is nicer, the language is easier to get into, it's more com…

(Minor typo corrections; "Biopython", not "BioPython" and "strcmp" not "strcomp". I co-founded Biopython. We chose to avoid CamelCase.)

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

#65

Post by sgt101 »

GFK_of_xmaspast wrote: post #6
zzleeper wrote: post #2

Quite interesting post. I feel that a lot of the numerical Pythonistas are in the same spot: They tolerate most languages, but find R's syntax a bit unnatural, Matlab lacking when trying to go beyond pure matrix stuff, and are waiting to see if Julia picks up (which it seems to be from what I can tell)

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)

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

#66

Post by a_bonobo »

dalke wrote: post #64
a_bonobo wrote: post #39

>I think it [Perl] is still quite common in the bioinformatics field though!? That's true - many day-to-day tasks in bioinformatics are more or less plain-text parsing [1], and Perl excels in parsing text and quickly using regular expressions. "My" generation of bioinformaticians doing data cleanup and analysis (20-30) uses Python, sometimes because plotting is nicer, the language is easier to get into, it's more com…

(Minor typo corrections; "Biopython", not "BioPython" and "strcmp" not "strcomp". I co-founded Biopython. We chose to avoid CamelCase.)

Sorry about that, that's what happens in caffeine-less typing - I sadly can't fix it at this point anymore, edit is disabled now

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

#67

Post by sgt101 »

jordigh wrote: post #31
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.

They've been trying to Javaify the Matlab syntax for close to two decades now. They're moving towards making everything an object like in Java. They're getting pretty close to that.

One of the lessons of Julia for me is that everything is an object is a problem, not a boon. I think organizing code in modules with sets of related types and functions manipulating those types allows more natural and modular decompositions for reuse.

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

#69

Post by syllogism »

srean wrote: post #53
rasbt wrote: post #44

Earlier quoted context omitted.

I agree with you. However, note that many people who are using Python for writing scientific code make use of C/C++ in one way or the other (aside from NumPy, SciPy, and Theano). For example, many people write the "most intensive" computations down in C/C++/Cython if they call those functions frequently -- Python becomes a wrapper. One example that pops into my mind is khmer ( https://github.com/dib-lab/khmer )

This is a common refrain: drop down to C, C++, Fortran for the computation intensive parts. It works, but only to a degree. The inefficiencies lie in the vectorization semantics of the host language(s) that leads to extra copies and extra levels of indirection. So this dual language mode of operation typically does not approach what one could have obtained had one disposed the baggage entirely, except for I/O. Usuall…

You don't have to use the vectorization though. I prefer to work with Cython and just use pointers. You don't get to write vector + vector --- you have to actually write the loop --- but that's not such a big deal imo.

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

#70

Post by [deleted] »

srean wrote: post #53
rasbt wrote: post #44

Earlier quoted context omitted.

I agree with you. However, note that many people who are using Python for writing scientific code make use of C/C++ in one way or the other (aside from NumPy, SciPy, and Theano). For example, many people write the "most intensive" computations down in C/C++/Cython if they call those functions frequently -- Python becomes a wrapper. One example that pops into my mind is khmer ( https://github.com/dib-lab/khmer )

This is a common refrain: drop down to C, C++, Fortran for the computation intensive parts. It works, but only to a degree. The inefficiencies lie in the vectorization semantics of the host language(s) that leads to extra copies and extra levels of indirection. So this dual language mode of operation typically does not approach what one could have obtained had one disposed the baggage entirely, except for I/O. Usuall…

[deleted]
Post reply on HN