Live data from Hacker News

Julia: A fresh approach to numerical computing

arxiv.org

101–110 of 146 posts

Re: Julia: A fresh approach to numerical computing

#101
post #14
post #8

Earlier quoted context omitted.

What I'd like to know when learning a new language is: why can't this be done in an existing language? Take for example the R programming language. Things you do in this language can be perfectly well done in e.g. Python too. Same goes for the MATLAB language.

Julia is homoiconic, so it can do things non-homoiconic languages can't do. E.g. symbolic differentiation of Julia expressions. Of course Lisp and Scheme can do this too, but it's virtually non-existent in any common language today. SICM makes heavy use of this. Now, is there any other language with Lisp-like macros and static typing?

When do you call a language "homoiconic" exactly? When it exposes its own AST (abstract syntax tree) structure? In that case, you can call any language homoiconic, whenever somebody builds a library that can transform a given AST back into executable code.

I'm not sure if it is a very distinctive feature.

Re: Julia: A fresh approach to numerical computing

#102

Earlier quoted context omitted.

The point was that object.method() is sometimes more readable . For example I find web_socket_manager.reconnect_if_needed() more readable than reconnect_if_needed(web_socket_manager).

That's because you are used to thinking in terms of objects, whereas in Julia the focus is on data and operations on data (the two are often conflated but they aren't the same).

I think in both depending on the situation.

Re: Julia: A fresh approach to numerical computing

#103

Earlier quoted context omitted.

I wish there was a language like Julia but with a first-class OOP support. Sometimes the OOP approach is more readable and easier to reason about than functional approach.

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.

Re: Julia: A fresh approach to numerical computing

#104

Earlier quoted context omitted.

For reference, a staged function is something sorta similar to a macro, except it lets you take advantage of Julia's inferred type info. Contrived (and wholly redundant) example: stagedfunction foo(x) if x == Int :(2x) else :x end end y = 1 foo(y) == 2 y = 1. foo(y) == 1.0 Again, just like a macro, except that before `x` is quoted you work with the type of y instead of the symbol `y`. This means you can do even more…

This sounds very similar to an approach called Lightweight Modular Staging (pioneered in Scala by the Oderski group - http://scala-lms.github.io/ and also in Lua - http://terralang.org/ ). While this is great for specializing numeric code based on runtime invariants like dimensionality, I think people are finally looking at using the idea in other domains - for example, runtime generation of DSL code on a per instant…

You mean like blaze in python?: http://blaze.pydata.org/docs/v_0_6_5/index.html

Re: Julia: A fresh approach to numerical computing

#105

For anyone in the Chicago area, Leah Hanson is giving a free Julia workshop next weekend (11/15): http://www.meetup.com/JuliaChicago/events/216950712/ Should be a great way to get introduced to the language and pose your nagging questions to a community expert.

Her blog is also a great resource to pick up some of the more useful parts of the language.

Not to mention her forthcoming O'Reilly book, "Learning Julia"!

Re: Julia: A fresh approach to numerical computing

#106
post #81
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…

Dictionary performance is still slow from what I can't tell. Like 2x slower than Python last time I checked. https://groups.google.com/forum/#!topic/julia-users/hxfR70Ro... I also find the dataframe library to be much harder to use/not much faster than pandas. Great community though.

Right now, DataFrames is handicapped by problems with how DataArrays was designed. With some revisions coming in Julia 0.4, it should be possible to fix a lot of the worst problems (esp. performance) with DataFrames.

Re: Julia: A fresh approach to numerical computing

#107
The biggest challenge I'm facing now is how to convince those around me to take the leap and step over to Julia. We have a wealth of legacy code in MATLAB, C++ and Fortran. I've seen the various methods to call these codes from Julia, but in the case of C++, it seems that only rudimentary support is provided.

My goal is to port a lot of my code to set up astrodynamics simulations. I've even created a placeholder Github repo for it [1]. Just have to find the right strategy to involve the dev in my existing projects and get my colleagues to chip in.

[1] https://github.com/kartikkumar/Astro.jl

Re: Julia: A fresh approach to numerical computing

#109
post #47
post #4

What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn'…

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.

Re: Julia: A fresh approach to numerical computing

#110
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 write them out as explicit loops then JIT will take a stab at making things faster.

I do like the economy of words of vectorized expressions a whole lot, this is the reason why I am so excited about https://github.com/lindahua/Devectorize.jl

Post reply on HN