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

The Julia Programming Language

julialang.org

Post reply on HN
Print view View original

121–130 of 211 posts

Re: The Julia Programming Language

#121

Post by chancho »

ViralBShah wrote: post #88
wbhart wrote: post #33

Earlier quoted context omitted.

It would certainly be nice if there was an option to use 0 based indices in blocks of code. It's understandable in that they are pitching at the technical community, and many mathematical papers and books are written with 1 based indices. But I am a mathematician who prefers 0 based indices.

Actually, it is quite easy to implement 0 based indices or any other indexing scheme in julia, since all the array indexing code is implemented in julia itself. https://github.com/JuliaLang/julia/blob/master/j/array.j#L15... I personally would find multiple indexing schemes confusing both for usage as well as to develop and maintain. Given that 1 based indexing seems to be a popular choice among many similar language…

Have you looked at the Haskell Ix class? http://www.haskell.org/onlinereport/ix.html

It generalizes the choice of 0 or 1 to an arbitrary starting index. So when you create an array you specify not just where it ends but also where it begins. This lets you do neat things (consider a filter kernel with range [-s,+s]^n instead of [1,2s]^n) and the extra complexity it adds can be hidden when not needed using for-statements or higher order functions.

Nobody uses it because the implementation is not very efficient and Haskellers have a chip on their shoulder about performance. It subtracts the origin and computes strides on every index, but you could easily avoid this by storing the subtracted base pointer and strides with the array. Of course when you go to implement it you'll see light on 0-based indexing :)

Re: The Julia Programming Language

#122

Post by pron »

StefanKarpinski wrote: post #119
dkarl wrote: post #112

Earlier quoted context omitted.

in any language where objects are boxed, it becomes very tricky. We're working on it, however Naive question (and I'll hold my tongue on my naive guesses): I understand why it is necessary to box user-defined types on the JVM, but why build this restriction into a new language that doesn't run on a restricted platform? Especially when performance and C interop are high priorities? Or perhaps I misunderstood, and your…

Boxed values are pretty much necessary for dynamic languages — that's where the information about what kind of value something is gets stored. It is a pain for this kind of thing, however. In a fully statically compiled language like C, however, you can eliminate the need for a box entirely. If you want dynamic typing, that's the price we've gotta pay.

Not necessarily. You just store a pointer to the type info inline with the data (like C++'s vtables). You can have unboxed "value-types" (const structs, essentially) in dynamic languages. In fact, you could even differentiate between a "boxed" ref type and a value type at runtime, because refs don't need all 64 bits of the pointer. So a ref is a 64 bit pointer with the first bit set to, say, 0, and a value (struct) type always begins with a 64 bit pointer to it's type information, only it's tagged with MSB of 1. Since you can't extend concrete types, you can easily store value types inline in an array, and just have the type-info pointer (which must be the same for all elements, b/c there is no inheritance) at the beginning of the array. And if your structs are aligned OK, you could easily pass them to C by skipping the type-info pointer both in the single value case and in the array case.

Re: The Julia Programming Language

#123

Post by wbhart »

StefanKarpinski wrote: post #94
wbhart wrote: post #86

Earlier quoted context omitted.

Great news about the operators. I didn't see an example of overloading there, but I probably rushed through it a bit quickly. I have been working on and off on a BSD licensed bignum library. Maybe in a few years....

If you happened to feel like trying to port it to Julia, it would be fairly doable. All the low-level functionality is there to allow it — bit twiddling operations, growable dense arrays of integers, etc.

Unfortunately the performance would be poor. This is not a reflection on Julia. Even compiled C is between 4 and 12 times slower than assembly for some bignum operations.

Also, LLVM handles carries and certain loop optimisations poorly, so even using LLVM bytecode you can't do much better than compiled C. It would be a massive project to improve this in LLVM (I thought about giving it a go sone time ago but decided it was overwhelming). And that use case is probably too specialised for the improvements to help with much else. Obviously the LLVM backend is fantastic for 99% of use cases and improving all the time.

N.B. I am not implying that a good assembly programmer is generically faster than a C compiler. Bignums are a very special case.

Re: The Julia Programming Language

#124

Post by olaf »

bandarman wrote: post #100
ViralBShah wrote: post #77

Earlier quoted context omitted.

Is it due to openblas not building? This may help: https://github.com/JuliaLang/julia/issues/370

Thanks for your suggestion. I tried that, but it wasn't it. I'm still getting lots of build errors, culminating with this: Saving to: `lapack-3.4.0.tgz' 2012-02-19 01:03:26 (55.3 KB/s) - `lapack-3.4.0.tgz' saved [6127787/6127787] make[3]: gfortran: Command not found make[3]: * [lsame.o] Error 127 /bin/sh: ./testlsame: not found /bin/sh: ./testslamch: not found /bin/sh: ./testdlamch: not found /bin/sh: ./testsecond: n…

Is package gfortran installed?

Re: The Julia Programming Language

#125

Post by sparky »

StefanKarpinski wrote: post #65
_delirium wrote: post #49

Earlier quoted context omitted.

I believe what they're saying is that there are two things: 1. The Julia core, which consists of the language runtime and core functionality, is MIT licensed, and builds into an MIT-licensed shared library. 2. The Julia "environment", which includes a user interface, third-party libraries, etc., some of which are GPL, and which is therefore GPL as a whole. I believe they're saying that you can link #1 with proprietar…

That is exactly right. At the moment I think the only GPL library Julia uses is readline — but obviously that's pretty important for the repl, so we chose to do it this way.

The last REPL I wrote used linenoise ( https://github.com/antirez/linenoise ) instead of readline, and it worked great for us. You may need more of readline's features than we did, but it's worth a look.

Re: The Julia Programming Language

#126

Post by olaf »

bandarman wrote: post #72

Anyone else having compile issues? I'm on Ubuntu 11.10 (Server x64) and make fails consistently.

Yes, I get some 32-bit issues, gfortran and some packages (-dev) were not installed, still getting an error 139:

JULIA sys0.ji Segmentation fault make: [sys0.ji] Fehler 139

Re: The Julia Programming Language

#127

Post by dkarl »

StefanKarpinski wrote: post #119
dkarl wrote: post #112

Earlier quoted context omitted.

in any language where objects are boxed, it becomes very tricky. We're working on it, however Naive question (and I'll hold my tongue on my naive guesses): I understand why it is necessary to box user-defined types on the JVM, but why build this restriction into a new language that doesn't run on a restricted platform? Especially when performance and C interop are high priorities? Or perhaps I misunderstood, and your…

Boxed values are pretty much necessary for dynamic languages — that's where the information about what kind of value something is gets stored. It is a pain for this kind of thing, however. In a fully statically compiled language like C, however, you can eliminate the need for a box entirely. If you want dynamic typing, that's the price we've gotta pay.

As a compromise, I think it would be helpful to be able to define structs that have a known layout in memory but no dynamic identity. They would be treated like primitive types in Java, but with the crucial difference that users could define their own. That way users could write Julia code that stores and accesses data in the same format they need for interoperating with whatever native libraries they use, instead of serializing and deserializing between Julia objects and C struct arrays (or using int or byte arrays in their Julia code and giving up most of the advantages of a modern programming language.)

Re: The Julia Programming Language

#128

Post by Peaker »

StefanKarpinski wrote: post #74
ludwigvan wrote: post #56

Earlier quoted context omitted.

Actually, broadly speaking, I think math (think summation etc.) in general is usually 1-index based while programming is 0-index (due to memory locations so that the array index also points to the first element?). Also see Dijkstra's take on the matter: http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF for

At first we were going to use 0-based indexing, but it made porting any Matlab code over very hard, which defeats a large part of the purpose of having Matlab-like syntax in the first place — to leverage the large amount of Matlab code and expertise that exists out there. However, as I've used it more and more, 1-based indexing has really grown on me. I feel like I make far fewer off-by-one errors and actually hardly…

We shape our tools and then our tools shape us.

Be careful when generalizing from your own personal preferences and cognitive biases to what is easier for humans in general.

Re: The Julia Programming Language

#129

Post by ViralBShah »

StefanKarpinski wrote: post #65
_delirium wrote: post #49

Earlier quoted context omitted.

I believe what they're saying is that there are two things: 1. The Julia core, which consists of the language runtime and core functionality, is MIT licensed, and builds into an MIT-licensed shared library. 2. The Julia "environment", which includes a user interface, third-party libraries, etc., some of which are GPL, and which is therefore GPL as a whole. I believe they're saying that you can link #1 with proprietar…

That is exactly right. At the moment I think the only GPL library Julia uses is readline — but obviously that's pretty important for the repl, so we chose to do it this way.

There's also FFTW and parts of SuiteSparse, which are GPL.

Re: The Julia Programming Language

#130

Post by kylebrown »

I'm more concerned with visualizing the data than with compiler optimizations or types/operators.

I see that d3.js is included in the package, but a cursory glance at the docs and I didn't see any examples of how to generate a chart.

Post reply on HN