

Julia for Numerical Computation in MIT Courses - sharmi
https://github.com/stevengj/julia-mit/

======
0x09
> Traditionally, these sorts of courses at MIT have used Matlab

This is an incredibly good sign for hobbyists in a number of fields where
Matlab completely dominates the research end of the spectrum. In the DSP realm
the amount of experimental software that relies on Matlab and the number of
research publications that pack in Matlab implementations is enough to be a
pain in the side for anyone outside of an institution where Matlab licenses
are taken for granted. Hopefully it will become a trend.

~~~
Bjoern
Octave?

~~~
dagw
Octave is close enough to Matlab to have inherited most of its flaws, yet not
close enough to be a complete drop-in replacement. Julia, while obviously
inspired by Matlab, is not attempting any sort of comparability, and thus can
fix flaws and be a better language.

Octave, in my opinion, should be relegated to (trying to) run legacy Matlab
code, while Julia or Numpy should be the first choice for any new code.

~~~
jordigh
> Octave, in my opinion, should be relegated to (trying to) run legacy Matlab
> code, while Julia or Numpy should be the first choice for any new code.

Octave dev here. I agree.

Every time I have to implement yet another idiocy of the Matlab language, I
die a little inside. It's a dirty job, but someone has to do it.

~~~
taliesinb
Come work on a modern functional language!

~~~
jordigh
You mean mathics? Perhaps. I don't know how important it is to liberate
mathematica code. It doesn't seem to have the deployment that Matlab has.

------
forkandwait
I tried to get into Julia, but I was put off when it seemed that the language
doesn't support vectorization the way that Matlab does, but rather encourages
writing your loops explicitly (which is fast due to the LLVM JITC). Yuck.

I am an Octave / Matlab fan myself, and think that Julia/ Python/ R/ etc don't
quite hit the sweet spot for matrix driven algorithms and 100-1000 line
programs that Matlab does. Call me old fashioned....

~~~
idunning
Julia does support vectorization just like MATLAB, but I think what you may be
referring to are some of the speed traps that currently exists where
undesireable/unnecessary copies occur. This is often in practice the reason
that writing devectorized code is better in Julia right now.

But, this issue is well-identified in the Julia dev community, and is on the
roadmap for 0.3:
[https://github.com/JuliaLang/julia/issues/4853](https://github.com/JuliaLang/julia/issues/4853)

------
Hansi
This seems like a strange choice to me, the only reason for choosing Julia
seems to be for speed but when doing any of these courses I can't see speed
being much of an issue but rather the ability to leverage existing code and
help available online and offline to learn the core mechanics of numerical
programming.

In my opinion Julia is great but still a bit immature.

~~~
gajomi
It may indeed be a strange choice, but I think there are many reasons for why
one might try Julia beyond the speed aspect. The main one for me (and I think
the language designs also state something to this effect) is the language wide
paradigm of multiple dispatch on parametric types. Coming originally from a
C/Fortran old school numerical computing background, it seems to me that many
of the best numerical software (your lapacks,fftws, and whatnot) eventually
end up at a point where you have a flat collection of a bunch of foo functions
with some protocol over the function suffixes and signatures, so that you can
can get at an optimized foo_* at the bottom level with a uniform interface
through a top level foo at the level of granularity of basic fooness as
understood by end users. Julia formalizes this structure, which is I think
part of how it achieves speed, but more importantly allows people to focus on
programming to the essential abstraction and adding in methods to optimize or
specialize after the fact.

~~~
StefanKarpinski
I love this post – you really get it :-)

------
tanvach
A question: are you getting good performance from Julia? I've seen posts that
say so, but my code that does Monte Carlo simulation (both vectorized and
devectorized) seem to be very very slow compared to Matlab or Numpy.

~~~
dagw
I've been testing Julia on and off for the past few month (rewriting various
bits of real world numpy code I've written for work) and I've seen everything
from 2 times slowdown to 20 times speedup when compared to numpy. Most of the
time I'm not seeing much more than 2 times speedup.

------
carterschonwald
Hehe. Get them while they're young.

I'll have to take a look see through this and write out the analogous code
with my Numerical Haskell libs after the holiday season to compare.

~~~
maximilian
Please do! I've been keeping an eye out for a post from you on the haskell
subreddit announcing some work.

I have some ideas for some numerical code in Haskell, but I keep coming back
to numpy/julia/matlab for my day-to-day.

~~~
carterschonwald
You could also subscribe to the mailing list I have setup on my website at
WellPosed.com, though I will cross post to reddit and Haskell cafe once it's
released (will be pre Alpha quality mind you). I'm aiming for sometime after
Xmas or around New Years.

------
dima55
So is Julia intended to be a general purpose language? I keep hearing about it
only in the context of numerical computation.

~~~
pjmlp
It started as a language targeted for numerical computation.

But as usual, many developers resist to "use the best tool for the job"
instead of "a language to rule them all", and Julia is now starting to have
libs for everything.

Not that is bad, quite the contrary. The language is quite nice and already
achieves C like speedups for many of its features.

So I can easily see it getting a place in the mainstream.

------
mckoss
Why is the IPython and scientific package installation always such a
nightmare?

~~~
dima55
Because some people like to use operating systems that don't have software
installation and maintenance figured out.

    
    
        apt-get install ipython
    

Done.

~~~
coldtea
That doesn't solve the problem. Here's another version:

Why is installing a specific version of a package you fancy (e.g the latest or
some previous) a nightmare?

And there "apt-get" doesn't help you much.

~~~
yummyfajitas

        pip install mypackage==1.2.3
    

I believe the general formula is apt-get for python and python-pip, then use
pip for everything past that point.

And in general, virtualenvs are the right way to go for anything other than
throwaway scripts. I've got a global numpy/scipy/requests install so that I
can just do `ipython -pylab` and start getting work done. But real project
code happens in a virtualenv.

On a mac anaconda works pretty well. I sent a link to a marketer with minimal
python experience and she was up and running in under an hour. (Admittedly,
she's rather more adept than a normal marketer...)

------
af3
hm... why teach Julia, if everything (90%) in numerical/scientific community
is Fortran/C(++) ?

~~~
dagw
Far from 90% of code written in the numerical world is Fortran/C. And even the
code that end up being written in Fortran almost always starts its life in
something like MATLAB or Python. Only after all the kinks have been worked out
and all the bottle necks identified might some of the code be ported to
Fortran or C. And even in those cases it often only makes sense to rewrite the
most critical 10%-20% of the code.

~~~
ovis
Agree with the above.

In addition, all of these higher level languages popular in science seem to
have pretty good support for calling existing C/Fortran libs when necessary.
Julia is no exception, which makes it possible to take advantage of all the
work that's been done developing optimized numerical codes.

That said, I would like to see something more automatic. In my limited
experience, Julia's ccall works as advertised, but f2py in Python is much
simpler to use.

