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

Julia 1.0

julialang.org

Post reply on HN
Print view View original

151–160 of 446 posts

Re: Julia 1.0

#151

Post by rrock »

taliesinb wrote: post #53

I'd love to know from any resident Julia experts: what are your favorite examples of active, high-quality Julia packages? And perhaps more importantly, what is missing?

For me, Images.jl. The design is just great, and a lot of work (mostly from Tim Holy at WUSTL) went into the array handling code of base Julia and of Images.jl to make it all fast and easy to use.

I'll give you one quick example of the design. Images are just arrays of "Colors". The upside is that you can write generic code that handles arrays of Colors of any kind, meaning you don't have to worry about iterating over the color axis. You also don't have to worry about whether your 100x100x3 array is three images (at different times or locations) or one image with three RGB channels. All of this comes at little to no cost in terms of speed.

Check the docs here: http://juliaimages.github.io/latest/

But fair warning, it still needs some fixes for 0.7/1.0. We're on it!

Re: Julia 1.0

#152

Post by gjm11 »

simonbyrne wrote: post #145
gjm11 wrote: post #138

I wanted to give this a try with Jupyter (having played a bit with earlier versions of Julia that way) but haven't had much success. It seems that the first step in getting Jupyter to know about a new version of Julia is to do Pkg.add("IJulia") in Julia. Except that that doesn't work; it seems that now you're supposed to use some special pkg mode in the Julia REPL. So, I hit ] to enter pkg mode and type "add IJulia",…

No, just need to wait for IJulia to be updated. I imagine it will be a day or two.

Fair enough (though it looked as if at least some of the trouble was not inside IJulia).

I thought it might be interesting to try the Juno IDE, but met with a similar lack of success: first of all it told me I needed to do Pkg.add("Atom"); when I had done (not that but) the approximately equivalent ]add Atom, starting Juno yielded only a cascade of error messages (no method matching eval(::Module, ::Expr); failed to precompile Media; failed to precompile Juno; failed to precompile Atom).

Presumably, again, the answer is to wait a little for things to settle down. It feels as if it might have been better to get all the ducks in a row before declaring version 1.0, though...

Re: Julia 1.0

#153

Post by ChrisRackauckas »

athenot wrote: post #147

As an outsider, I'd like to see somewhere near the home page a few short snippets of code to get a feel for Julia and hopefully show the kind of uses for which it is a natural choice. Nim's home page¹ shows a piece of sample code right at the top. Perl6's page² has a few tabs quickly showing some patterns it's good at. Golang³ has a dynamic interpreter prepopulated with a Hello World. Julia's home page shows a nice f…

For scientific computing, showing the package ecosystem is the most important thing. When you look at this thread, people are asking about dataframes and differential equations. Julia's site reflects this: yes there are things like Pandas, and for plotting, etc.

Re: Julia 1.0

#154

Post by simonbyrne »

kmm wrote: post #142
currymj wrote: post #51

Earlier quoted context omitted.

Apart from being close to MATLAB, a goal of Julia is to make it easy to just type mathematical formulas straight off the page and into your code. 1-based indexing makes this so much easier, even if it seems somewhat depraved to a computer scientist.

In my experience, 0-based indexing is way more common in mathematics. Maybe it depends on the field you're working in. Off the top of my head, dimensions are numbered from zero in relativity and particle physics, Fourier series only make sense with 0-based indexing, coefficients of polynomials are numbered from zero, Taylor series, indexing by taking the modulo ...

A slight quibble: FFTs are more naturally indexed periodically. Luckily, Julia has that covered: https://github.com/JuliaArrays/FFTViews.jl

Re: Julia 1.0

#155

Post by AriaMinaei »

StefanKarpinski wrote: post #150
AriaMinaei wrote: post #141

Never had a proper look at the documentation until now. This language is very interesting! One thing I found is that types in Julia are first-class values [0]. You can put them in variables, pass them around, inspect them, even produce new ones in runtime. Opens up all kinds of metaprogramming opportunities. Very Lispy! (Well, Julia is Lispy). It's also interesting that types are optional, yet they're significant for…

> Like, if you do type the arguments of a function, the optimising compiler will have less work to do. Giving types for function arguments doesn't actually have any effect on performance: the compiler specializes on concrete runtime argument types anyway, so completely untyped code is just as fast as fully type annotated code—since the types are known when the code is compiled. On the other hand, giving type informat…

Thanks for the correction!

Re: Julia 1.0

#156

Post by KenoFischer »

civility wrote: post #134
peatmoss wrote: post #62

Earlier quoted context omitted.

> 1-based indexing now seems like a poor choice since Julia has become something more than the original mission of a better MATLAB or Octave. It’s a, admittedly, minor tragedy of Julia’s success. I’m curious as to why this is a problem outside numerical computing. From my perspective, this is consistent with a long history of mathematics dealing with matrices that predates electronic computers. 0-based arrays are pop…

Zero based arrays are frequently better in a numerical context. Many times when you’re using the index in the computation itself (FFTs for instance), zero based is what you want. For instance, the zeroth frequency (DC) is in the zeroth bin.

Which is why julia doesn't make any assumptions on how your axes are indexed. If you're working in a numerical domain where 0-indexed arrays, or symmetric arrays about the origin, or arbitrarily other transformed axes make sense, just use those.

Re: Julia 1.0

#157

Post by ur-whale »

weatherlight wrote: post #116
ur-whale wrote: post #90

Earlier quoted context omitted.

It most certainly is for the vast number of folks who code in C, C++, Java, Python, etc ... It will for sure hurt adoption.

I'm pretty sure if people are willing to adopt a new language, they will be open minded enough to accept 1 indexed arrays.

History has shown the exact opposite.

Re: Julia 1.0

#158

Post by simonbyrne »

gjm11 wrote: post #152
simonbyrne wrote: post #145

Earlier quoted context omitted.

No, just need to wait for IJulia to be updated. I imagine it will be a day or two.

Fair enough (though it looked as if at least some of the trouble was not inside IJulia). I thought it might be interesting to try the Juno IDE, but met with a similar lack of success: first of all it told me I needed to do Pkg.add("Atom"); when I had done (not that but) the approximately equivalent ]add Atom, starting Juno yielded only a cascade of error messages (no method matching eval(::Module, ::Expr); failed to…

Actually, you can try 0.7: this is more or less equivalent, but is backwards compatible with 0.6 (it will warn when incompatible uses are used).

Of course, more time would have been nice, but you can always find a reason for a delay. At some point you have to rip off the bandaid.

Re: Julia 1.0

#159

Post by ur-whale »

goatlover wrote: post #131
ur-whale wrote: post #94

Earlier quoted context omitted.

Yeah, same here. Once I hit on that, it was really hard to convince myself to read further.

You do realize that 0-based indexing is mostly because of C's huge influence and not because it's natural to higher level languages, particularly ones that are designed with scientific computing in mind. Fortran existed before C. It's also not hard to get used to. No more OB1 errors.

>No more OB1 errors

That makes no sense. Neither 1-based indexing or 0-based indexing will save you from OB1 errors.

As a matter of fact, if you make more OB1 errors in a 0-based indexing language, it's probably because your brain is wired to think 1-based.

The problem: there are legions of programmers whose brain is wired to think 0-based and are guaranteed to suffer through a lot more OB1 errors if they try to adopt Julia.

0 based indexing is not because of C's influence. It's because that's how computers work. ASM is 0-based indexing. The first memory cell on a computer doesn't start at address 1.

Re: Julia 1.0

#160

Post by ChrisRackauckas »

Q6T46nT668w6i3m wrote: post #44
bsdubernerd wrote: post #39

I'm a quite happy Julia user, however I feel there are still some warts in the language that should have warranted a bit more time before banging 1.0 on the badge. Exception handling in julia is poor, which reminds me of how exceptions are (not/poorly) handled in R. Code can trap exceptions, but not directly by type as you _would_ expect. Instead, the user is left to check the type of the exception in the catch block…

Yeah, I agree with your comments about error handling. It’s far from ideal in non-interactive contexts. It’s especially disappointing since you could easily imagine something like Julia replicating Python’s success at transitioning code from interaction (e.g. Jupyter notebook) to production. I initially defended the choice, but I now agree that 1-based indexing now seems like a poor choice since Julia has become some…

This is what 0-based indexing looks like in data analysis:

>In order to read a csv in that doesn't have a header and for only certain columns you need to pass params header=None and usecols=[3,6] for the 4th and 7th columns:

https://stackoverflow.com/questions/29287224/pandas-read-in-...

Just reading that hurts me.

Post reply on HN