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

Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

sinews.siam.org

Post reply on HN
Print view View original

81–90 of 249 posts

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#81

Post by h8hawk »

pjmlp wrote: post #14
linkingday wrote: post #6

Can't wait for the language to be as widely used as Python or R. Been playing around with it at home since the 1.0 release and it really is a joy to use.

I wish that Python feels a bit of Julia's heat, as that might be the only way for more PyPy love.

Pypy is basically abandoned project. Main version is Python2 and It has poor support for python 3. The latest version They are supporting is python3.5. Beside that even with Pypy they wouldn't be even close to nodejs. Julia is on par with Fortran or C. Reason behind Julia amazing performance is its type system. e.g multiple dispatch and value types. Python lakes both. Python also has parallelism problem with GIL. Mypy team currently works on compiler based on static type annotation: https://github.com/mypyc/mypyc I think they could gain much more performance than Pypy.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#83

Post by xvilka »

SiempreViernes wrote: post #26
xvilka wrote: post #24

Julia needs something like IPython/Jupyter but without Python.

the "Ju" in Jupyter is for julia, do you mean you want Jupyter without the python support?

Yes, this is why I said "without Python".

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#84

Post by wycy »

dagw wrote: post #34
wycy wrote: post #16

Earlier quoted context omitted.

Fun fact: arrays in Fortran are also based on 1 by default, but they can be defined to start at 0, or even arbitrary negative numbers. The following are all valid: integer :: array1(5) integer :: array2(0:4) integer :: array3(5:10) integer :: array4(-4:4)

Julia also supports this (called Offset Arrays)

Interesting. Doesn't this solve the problem then for people who can't get into 1-indexed arrays?

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#85

Post by KenoFischer »

tombert wrote: post #80
lenticular wrote: post #66

Earlier quoted context omitted.

There's pretty big differences in usage between multimethods in Clojure and Julia. I've used both a decent amount. All functions in Julia are multimethods by default. If you don't use type annotations, a new method will be generated whenever you call the function with new argument types. This explicit type specialization is a very important part of why Julia can have such a consistently fast JIT despite its dynamicit…

Forgive a bit of ignorance here, but that doesn't sound terribly different than overloading functions in C++. Am I way off on that?

The difference is run-time (semantically) vs compile time. If you had overloading at runtime in C++, you wouldn't need virtual functions or any of the thousands of OO "patterns" (visitor, factory, etc.), that are working around the lack of this capability.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#86

Post by h8hawk »

you_owe_me wrote: post #48

The authors claim Julia is a general programming language, but after a few tries I am not totally sure about that. Yes, it's a nice programming language for scientific computing but I am afraid its usefulness stops there. Matlab is (was?) the default tool for computational science, and Julia borrows lots from it. I'd say it's safe to put Julia in the same category with Matlab and Mathematica

People are using Javascript or python for real production. How those are general purpose and Julia is not?

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#87

Post by baldfat »

contravariant wrote: post #64
baldfat wrote: post #7

Earlier quoted context omitted.

So does: APL, AWK, COBOL, Fortran, Lua, Mathematica, MATLAB, R, Smalltalk, Wolfram Because it is Mathmatics and have 1 be based on 0 makes no sense, you then have to switch between the two and it is easy to make a mistake. This is why I don't use Python and Pandas. I got burnt once and that was enough and switched to R. Sadly we are stuck with 0 based array in programming and due to a historical issue.

For what it's worth mathematics is more than flexible enough to handle both 0 and 1 based indexing. Using 1 based just looks neater since you can count x_1, ..., x_n rather than x_0, ..., x_{n-1}. Sometimes both are used at the same time e.g. if you add an extra coefficient at the start rather than at the end, this happens particularly when dealing with wedge products where the parity of the new index matters. Also i…

The issue is 1 will mean different things. That should be a bigger issue than anything else. When you are doing math

1 + 1 = 2 always means two. When you are getting the 1 column we are getting the second column. This while makes sense when doing certain lower level programming this makes no sense with functional or higher level programming.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#88

Post by coldtea »

umvi wrote: post #72
coldtea wrote: post #67

Earlier quoted context omitted.

> It's not the 0th element. It is the 1st element and has an offset of 0 from the beginning of the array. It should be indexed with its position then a[1], as we do in all other aspects of life (and in math), and not with it's offset.

> as we do in all other aspects of life You mean like elevators? You may be surprised to learn that elevators in America are 1-indexed (ground floor == floor 1), but in Europe they are 0-indexed (ground floor == floor 0).

As a European I'm not really surprised, but it's not exactly the same thing. It's not like the ground level is considered "the 0th floor" and thus we use 0-based indexing.

In most European countries the ground floor is not considered the same thing as the others. As Wikipedia puts it: "In most of Europe, the "first floor" is the first level above ground level".

We consider and count as floors the "layers" above the ground level. In french for example, the ground level is called "rez-de-chaussée" and the floors above it "XX étage". The ground level is not an "étage" (in American terms, the "ground level" is not considered a floor, and is not counted among the floors).

For this reason, apart from elevator labels nobody calls the ground level "the 0th floor" when speaking/writing.

And even in elevators, O is just used as a convenient way to convey the ground level (since the buttons don't fit much) -- and not everywhere. In many elevators it gets it own designation (e.g. G or GRD or some other national variety).

It's "the ground level" (with different names per country) + "N floors".

A multi-floor building with ground floor + 3 floors can even named "3rd-storey building" in some countries (and the ground level is just taken as granted) -- e.g. une maison à deux étages in the UK --> 3 story building in the US.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#89

Post by vanderZwan »

GlenTheMachine wrote: post #79
tombert wrote: post #39

I built a very simple neural-network app a few years ago with Julia, and while the project was fun and I didn't think the language was bad by any means, as someone who does software for a living I had trouble seeing why compsci people really got into it. I could totally see someone like my dad using it (he's an aerospace engineer, not software), but I have friends who work in compsci in academia trying to evangelize…

In a nutshell: it combines the modern language features a CS person expects with the numerical excellence of Matlab. Is it a better language, from a pure CS perspective, than Python/Scheme/pickyourfavorite? No, not really. If your job is writing web pages, Julia will be fine but it won't excel. But if your job is writing trajectory planning routines for robots or climate simulations or so on, you aren't coming from t…

> Is it a better language, from a pure CS perspective, than Python/Scheme/pickyourfavorite? No, not really.

Could you be thinking more of a "pure developer perspective" than "pure CS perspective" perhaps? Because if anything I find Julia's type system a lot more interesting from a computer science point of view than Python or Scheme.

If I want to get things done, I'd stick to Python for now though due to sheer momentum.

Re: Julia Language Co-Creators Win James H. Wilkinson Prize for Numerical Software

#90

Post by dnautics »

tombert wrote: post #39

I built a very simple neural-network app a few years ago with Julia, and while the project was fun and I didn't think the language was bad by any means, as someone who does software for a living I had trouble seeing why compsci people really got into it. I could totally see someone like my dad using it (he's an aerospace engineer, not software), but I have friends who work in compsci in academia trying to evangelize…

I was playing around at work with some galois field stuff (very cs) and was very pleased to find that the lu decomposition for Julia "just worked" with the custom galois field type that I implemented. All in all about 75 lines of highly performant code, which is what I needed because I was conducting searches over 2^32 elements.
Post reply on HN