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

Julia: A fresh approach to numerical computing

arxiv.org

Post reply on HN
Print view View original

111–120 of 146 posts

Re: Julia: A fresh approach to numerical computing

#111

Post by ForHackernews »

StefanKarpinski wrote: post #93
ForHackernews wrote: post #74

Are there any mature visualization libraries for Julia yet? I'm pretty excited about this language, but I couldn't find any visualization tools that had good documentation.

Gadfly is an excellent ggplot2-style plotting package: http://gadflyjl.org Winston is a most traditional plotting API: http://winston.readthedocs.org/en/latest/examples.html You can also plot seamlessly via Python using PyPlot: https://github.com/stevengj/PyPlot.jl They are all quite well documented.

Thanks. I guess I would disagree with the assertion that Gadfly is "quite well documented". It has some docs, but they are mostly just a list of parameters (with no indication of what values you could/should set them to) and maybe one example, e.g. http://gadflyjl.org/geom_boxplot.html

Perhaps it's all very obvious if you're already familiar with ggplot2, but as somebody without an R background, I found their docs extremely spartan.

Re: Julia: A fresh approach to numerical computing

#112

Post by CyberDildonics »

gct wrote: post #97

The one based indexing pretty much kills the entire thing for me.

Then you are missing out on a wonderful programming tool for a very superficial reason. I wish indices were offsets like C and not indexes like Lua, but I'll deal with it for all the language gives.

Re: Julia: A fresh approach to numerical computing

#113

Post by RogerL »

phkahler wrote: post #109
wbhart wrote: post #47

Earlier quoted context omitted.

This very much depends on what you want to do with it and what your background is. Here are some things that might bother you. * Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm. * Julia's garbage collector is not generational/incremental and in some corner cases, GC can…

Arrays are indexed starting at 1. I asked about this and Jeff said it just depends which types of problems end up having to use +1 or -1. I said anything mod n is now going to have the +1 and he actually paused for quite a while. I know it's an unsolvable debate, but I thought indexing from 1 went out with Fortran. I also would have thought the math folks would prefer to start at zero.

Don't forget matlab starts at 1. R starts at 1. Mathematica starts at 1 by default, though you can override that for any given array.

1-based indexing is very common in mathematical software.

Re: Julia: A fresh approach to numerical computing

#114

Post by ViralBShah »

grayclhn wrote: post #89
jostmey wrote: post #78

Earlier quoted context omitted.

I've observed a huge performance boost over python -- I wrote a simple artificial neural network trained using backpropagation in both languages and my Julia code ran orders of magnitude faster. Something is clearly screwed up with your implementation of Julia. There is no way octave should be running faster.

Octave occasionally runs faster than Julia for transliterated vectorized vector and matrix operations. Julia then runs much faster when those operations are devectorized or replaced with builtin functions. But that's a pretty common source of these issues (at least on the mailing list.)

It would be good to know where we are slow, so that we can fix it. Can you for an issue with an example on github?

Re: Julia: A fresh approach to numerical computing

#115

Post by ViralBShah »

srean wrote: post #110
dagw wrote: post #77

Am I the only person not seeing the promised performance with Julia? As a concrete example I recently ported some non-trivial legacy matlab code I use at work to both python/numpy and Julia. The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. And much to my surprise Julia run twice as slow as Octave and 4 times as slow as python. Adding type annotations…

> The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. Then it is not surprising at all that you do not get any speed benefit. I would expect a serious slowdown. Idiomatic MATLAB and Numpy has lots of vectorized expressions because they are so crappy at loops. However, in vanilla Julia those vectorized expressions cannot be JIT'ed. Now if you were to wri…

On vectorized code we are on par usually, but sometimes GC performance hurts. There is a patch for this in the works. Could you post the code snippets to julia-users mailing list?

Re: Julia: A fresh approach to numerical computing

#116

Post by grayclhn »

ViralBShah wrote: post #114
grayclhn wrote: post #89

Earlier quoted context omitted.

Octave occasionally runs faster than Julia for transliterated vectorized vector and matrix operations. Julia then runs much faster when those operations are devectorized or replaced with builtin functions. But that's a pretty common source of these issues (at least on the mailing list.)

It would be good to know where we are slow, so that we can fix it. Can you for an issue with an example on github?

I'll do it right now. These aren't issues I've personally run across, though, just stuff on julia-users.

edit: Nevermind! On rereading the mailing list thread (especially this message [1]), I might have mischaracterized the issue slightly. It probably came from speed issues with small integer powers (i.e., there are faster ways to exponentiate small integer powers than there are for general exponentiation that Julia hadn't been using but other software like matlab and octave were), and that issue in Julia seems to be fixed now.[2]

[1] https://groups.google.com/d/msg/julia-users/n3LfteWJAd4/jag6...

[2] https://github.com/JuliaLang/julia/issues/2741

Re: Julia: A fresh approach to numerical computing

#117

Post by grayclhn »

RivieraKid wrote: post #103
grayclhn wrote: post #73

Earlier quoted context omitted.

That seems like a pretty decent description of python, right? :)

Yeah, I like Python but it's slow and Julia seems better designed in many ways :) I'm now using Julia when I don't need Pythin libs.

Check out the PyCall[1] and PyPlot[2] packages, then. Julia has pretty good integration with python. I've been pretty happy calling matplotlib from julia. (You probably already know about these packages, but just in case you didn't...)

[1]: https://github.com/stevengj/PyCall.jl

[2]: https://github.com/stevengj/PyPlot.jl

Re: Julia: A fresh approach to numerical computing

#118

Post by ViralBShah »

tomrod wrote: post #99
StefanKarpinski wrote: post #93

Earlier quoted context omitted.

Gadfly is an excellent ggplot2-style plotting package: http://gadflyjl.org Winston is a most traditional plotting API: http://winston.readthedocs.org/en/latest/examples.html You can also plot seamlessly via Python using PyPlot: https://github.com/stevengj/PyPlot.jl They are all quite well documented.

Still working my way through them myself. Useful examples working through docs would be useful. Most seem to presume a lot of knowledge of the libraries.

You are right - package documentation has some ways to go. Currently we don't yet have a mechanism to do `help()` on a package function, but we expect that to change in 0.4.

Re: Julia: A fresh approach to numerical computing

#119

Post by vegabook »

I am a little weary of the hype around a language whose unique selling point is speed. Where else in Julia is there significant innovation versus Python? The latter seriously has it all when it comes to scientific computing, and if anybody is not already running vectorized numpy code, or trivially compiling critical for loops to c-like speed using Numba/Cython, then they're missing out on performance which has nothing to be ashamed of versus any of the newer kids on the block.

I have been weary of the Julia pitch which was basically "lets brew R, Python, and Matlab (all >20 years old with massive and unrivalled ecosystems and all serving their purposes very well, thank you) into one "new" language and put a nice logo on it". How is this language seriously the leap forward that one needs to abandon the current awesome toolsets, with all their battle tested libraries, other than a nebulous "speed" argument which in many cases, judging by the comments and my own experience in financial data matrix operations, is not even fully accurate? Ready to be persuaded otherwise if I can be shown that other than "speed" there are hefty reasons to move from Python and abandon the almost endless choice of richly varied tools that I have at my disposal already.

Re: Julia: A fresh approach to numerical computing

#120

Post by ViralBShah »

kartikkumar wrote: post #108
ViralBShah wrote: post #49

Earlier quoted context omitted.

Shoot me an email - viral@mayin.org

Mind if I shoot you an email too for an invite?

Yes - happy to share codes with anyone. Also, we will be simplifying the invite system in the next few days so that JuliaBox will let you in without any code by default.

In the rare cases of a surge, such as an HN mention, it will auto-release account approvals as the surge subsides in a few hours. Once you do have access, you will continue to have access, even during surges. Basically, we are just trying to manage our compute budget better.

Post reply on HN