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

91–100 of 211 posts

Re: The Julia Programming Language

#91

Post by javajosh »

fijal wrote: post #40
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.

It seems like both 0 and 1 based arrays is asking for trouble :) I would prefer 0-based, but still prefer 1-based to mixed or optional.

We are scientists and so willing to compromise, yes? So how about 0.5-based arrays? :)

Re: The Julia Programming Language

#92

Post by ViralBShah »

StefanKarpinski wrote: post #76
kghose wrote: post #45

So, the usual caveats about writing code to match the languages strengths apply here. For example the fib function plays to a python weakness - function overhead. Rewriting the code to be a simple loop removes the inefficiency: import time def fib(n): if n

That's quite true, but this micro-benchmark wasn't chosen to make Python look bad — it was chosen to test how good each language was at function calls. So using a loop defeats the point of the benchmark. Using double recursion to compute Fibonacci numbers is also stupid and could obviously be avoided in all languages. The story the micro-benchmark tells is that Julia's pretty good at function calls, but JavaScript is…

Yes, I pretty much had the same thought, but then I started thinking about multiple dispatch, calling C/Fortran libraries, polyhedral optimizations, and I realized that V8 developers may not have the same design targets in mind.

Re: The Julia Programming Language

#93

Post by ViralBShah »

ludwigvan wrote: post #27

Very exciting. The real power of MATLAB likes in its toolboxes, though, I wonder if there will be an easy (and possibly automatic) way to convert toolboxes. One more thing: it would be awesome if the `manipulate` from Mathematica could be incorporated somehow in that web interface. See: http://www.wolfram.com/broadcast/videos/manipulate/

MATLAB toolboxes are simply awesome for users, even though they are expensive. We hope that if enough people find julia useful, many such libraries will be built. Having written a ton of mex and matlab stuff, and a lot of julia libraries, I find that julia is nicer to use personally - but of course I am biased. :-)

I do believe that open source + good compiler + simple C/Fortran calling interface will lead to others being able to write toolboxes in julia itself and plugin libraries when needed.

Re: The Julia Programming Language

#94

Post by StefanKarpinski »

wbhart wrote: post #86
StefanKarpinski wrote: post #64

Earlier quoted context omitted.

Thanks for the incredibly high praise. It definitely is possible to overload operators — operators are just functions with special syntax (see http://julialang.org/manual/functions/#Operators+Are+Functio... ). We don't have bignum support, but adding it via GMP would be fairly easy. Just too many things to do!

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.

Re: The Julia Programming Language

#95

Post by pron »

StefanKarpinski wrote: post #71
mjw wrote: post #26

I wonder what they think about or have learned from http://en.wikipedia.org/wiki/Fortress_(programming_language) , another recent-ish attempt to deliver a modern and powerful scientific programming language. Personally I'm a little wary of being ghettoised into something overly domain-specific for scientific/numerical computing. Really good interop may mitigate that -- something which can navigate the unholy mix of C…

I huge part of the goal here is to reduce the need for the "unholy mix of C, C++, fortran, matlab, octave, R and python routines" in both academic research work and machine learning / data science code in industrial settings. The whole project kicked off with me ranting about how I was sick of cobbling things together in six or seven different languages. So interop is a very, very high priority. We have pretty good C…

> Another major interop issue is support for arrays of inline structs

Oh, so arrays of complex numbers are implemented as arrays of pointers to objects? That would give really bad CPU cache performance.

Re: The Julia Programming Language

#96

Post by ViralBShah »

simonw wrote: post #24
kib2 wrote: post #19

No Windows support, really ?!

That's pretty common for new language implementations - Node.js was around for a couple of years before the Windows port was ready. To be honest, if you're targeting early adopters of a programming language Linux and Mac support is probably a lot more important than Windows. Smart Windows users can always run Linux in a VM.

It is true that a number of people do their scientific computing on Windows+Matlab or Windows+R, but that most parallel stuff is typically on linux clusters. It would be nice if julia worked on both.

It is not by design that we do not have Windows support. It's just that none of us uses windows. We do believe that code is largely portable, and with a little effort, it can be built on cygwin or mingw. Nothing like a native port though. Maybe someone who is familiar with windows will come along and contribute. This is a common question our friends and colleagues ask us.

Re: The Julia Programming Language

#98

Post by pron »

ViralBShah wrote: post #92
StefanKarpinski wrote: post #76

Earlier quoted context omitted.

That's quite true, but this micro-benchmark wasn't chosen to make Python look bad — it was chosen to test how good each language was at function calls. So using a loop defeats the point of the benchmark. Using double recursion to compute Fibonacci numbers is also stupid and could obviously be avoided in all languages. The story the micro-benchmark tells is that Julia's pretty good at function calls, but JavaScript is…

Yes, I pretty much had the same thought, but then I started thinking about multiple dispatch, calling C/Fortran libraries, polyhedral optimizations, and I realized that V8 developers may not have the same design targets in mind.

... and the JVM (HotSpot) is even better than V8.

Re: The Julia Programming Language

#99

Post by warmfuzzykitten »

When you try to install julia on MacOS X 10.7.3, you may see the make fail because wget is not installed. Easy to fix with:

brew install wget

[Edit] git page says gfortran (and wget) are downloaded and compiled, but if they're not already installed make fails. So...

brew install gfortran

The need to do this separately may have to do with licensing?

[Edit] And if you're not root, install to /usr/share/julia will fail. So you'll need to do:

sudo make install

I'm sure all this is perfectly obvious to Unix-heads who are inured to this sort of abuse, but I'm a Mac-head, used to things that Just Work, and I hate this shit.

Re: The Julia Programming Language

#100

Post by bandarman »

ViralBShah wrote: post #77
bandarman wrote: post #72

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

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: not found /bin/sh: ./testdsecnd: not found /bin/sh: ./testieee: not found /bin/sh: ./testversion: not found make[2]: * [lapack_install] Error 127 make[1]: * [lapack-3.4.0/INSTALL/dlamch.o] Error 2 make: * [julia-release] Error 2

Post reply on HN