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

181–190 of 249 posts

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

#181

Post by yellowapple »

dmix wrote: post #129
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.

+ Elixir: Regex and Binary indexes are zero-based, List and Tuple are one-based

Are they, though? The relevant functions in Enum all seem to be zero-based, for example:

    iex> [:foo, :bar, :baz] |> Enum.at(1)
    :bar
Not that it really matters anyway. Like with Erlang, in the vast majority of cases where I'd normally reach for querying a list element by index, pattern matching is the better / more idiomatic option. Compare:

    foo = list |> Enum.at(0)
    bar = list |> Enum.at(1)
    baz = list |> Enum.at(2)
    rem = list |> Enum.slice(3..-1)
with:

    [foo, bar, baz | rem] = list
Both give you the exact same values of foo/bar/baz/rem, but the latter is arguably more readable and concise, and entirely avoids the 0 v. 1 debate.

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

#182

Post by goto11 »

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).

It is not 0-indexed, it is just that "floor" means something different than in American English. It means a level above the ground. So the first level above ground is the first floor.

The German word Stockwerk is even clearer. It describes the wooden planks which separates two levels. So if you live on the first Stockwerk you live one level above ground.

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

#183

Post by viraptor »

civility wrote: post #75
Stubb wrote: post #38

Earlier quoted context omitted.

Python without GIL to provide real shared-memory threading would address 90% of my issues with the language.

In my experience, CPython is 100 to 1000 times slower than C (or C++, Rust, Fortran, etc...). CPython would be better off fixing the speed (perhaps by embracing PyPy) and staying single threaded than removing the GIL. At least if you're choosing threads for performance gains. Think of it this way: A single threaded C++ or Rust program can do more work per second than a hypothetical GIL-free CPython with 64 cores...

> CPython is 100 to 1000 times slower than C

That's very context dependant. With annotations, typical calculations compile to C code roughly equivalent to native. The more of the actual runtime you use, the more you call into cpython which can't be sped up this way. Cython compiled code will be somewhere between C and cpython in terms of speed, but putting a single number to it will be always misleading.

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

#184

Post by elcritch »

peteradio wrote: post #144
lenticular wrote: post #49

Earlier quoted context omitted.

Julia would be ideal for those task as well, but alas the libraries aren't there. Julia can easily call Python functions with PyCall, although I still wouldn't want to extensively use a complicated Python library in this way.

Seems like it would be better to call Julia from python.

Python doesn't have the typing support or even availability of many types. Calling Julia from Python in some cases would require something like cython or require even using the C api ahem.

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

#185

Post by elcritch »

dnautics wrote: post #90
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.

That's cool! What were using the galois fields for?

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

#186

Post by xiaodai »

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.

I recall that the main issue with PyPy is that it doesn't have as good interop with C and a lot of CPython codes just call C code and hence is difficult to widely adopt given the amount of reliance on CPython.

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

#187

Post by simondanisch »

nadam wrote: post #17
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.

0 based arrays is objectively the preferred way for me and not for historical reasons. I write a lot of low level graphics algorithm stuff, and 1-based arrays would complicate index arithmetic. like now with everything 0 based having something like: arr[offset1 * 32 + offset2] would be the following if all my offsets would be 1-based and arrays would be 1-based: arr[(offset1 -1) * 32 + offset2] which is pretty arbitr…

that may be your impression, because you dont know julia's powerful, no overhead indexing abstractions yet ;) i also write lots of graphics low level code, and i couldn't be more glad that i don't need to do those error ridden indexing calculations anymore, since they're simply not needed... note, that you can also seamlessly create new array types that store 0 indices into other arrays - and because of julia's great composability, i can make them work with my indexing agnostic algorithms while being 0 overhead compatible with opengl's memory layout :)

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

#188

Post by renox »

sephoric wrote: post #179
azhenley wrote: post #4

From the interview with the award recipients: “A programming language cannot be derived from first principles alone. Language design is applied psychology—the computer program is the ultimate human-computer interface. Sometimes you have to try a design out and see how people interact with it and iterate based on that real-world feedback.” I wish more people viewed PL like this.

That's why C is the way it is, for all the hate it gets. I've been teaching my son the beginnings of C now that he's proficient in JavaScript and Lua, but making sure that every step of the way, we jump from a concept he already understands, to a new but related concept, and how they're connected. For example, when I explained signed and unsigned to him, since we already covered the concepts of groups of bits having…

Well designed.. I'm not so sure, once you're used to something you're 'blind' to its defaults.. Big: signed/unsigned automatic conversion? Minor: conflating unsigned and modulo arithmetic (why not allowing signed modulo int?)? Huge: no way to pass an array but just a pointer? ...

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

#189

Post by dnautics »

elcritch wrote: post #185
dnautics wrote: post #90

Earlier quoted context omitted.

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.

That's cool! What were using the galois fields for?

this was interesting to me:

https://www.youtube.com/watch?v=Gh578e98qAk&t=567s

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

#190

Post by weberc2 »

viraptor wrote: post #183
civility wrote: post #75

Earlier quoted context omitted.

In my experience, CPython is 100 to 1000 times slower than C (or C++, Rust, Fortran, etc...). CPython would be better off fixing the speed (perhaps by embracing PyPy) and staying single threaded than removing the GIL. At least if you're choosing threads for performance gains. Think of it this way: A single threaded C++ or Rust program can do more work per second than a hypothetical GIL-free CPython with 64 cores...

> CPython is 100 to 1000 times slower than C That's very context dependant. With annotations, typical calculations compile to C code roughly equivalent to native. The more of the actual runtime you use, the more you call into cpython which can't be sped up this way. Cython compiled code will be somewhere between C and cpython in terms of speed, but putting a single number to it will be always misleading.

>> CPython is 100 to 1000 times slower than C

> That's very context dependant. With annotations, typical calculations compile to C code roughly equivalent to native. The more of the actual runtime you use, the more you call into cpython which can't be sped up this way. Cython compiled code will be somewhere between C and cpython in terms of speed, but putting a single number to it will be always misleading.

OP said "CPython", not "Cython". CPython is pretty reliably 100X to 1000X slower than C.

Post reply on HN