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

181–190 of 446 posts

Re: Julia 1.0

#181

Post by tavert »

stabbles wrote: post #75
jordigh wrote: post #70

> with a liberal license I hope Julia doesn't rely on inferior libraries just out of copyleft phobia. I would much rather use FFTW than FFTPACK or whatever other alternative they have in mind. FFTW is really best in class. I'm okay with them making FFTW optional, but please make it opt-out, not opt-in. People should be getting the best software by default. Copyleft isn't going to hurt anyone but people who are trying…

Many things in Base have moved to separate packages to make it light-weight. FFTW is available in a package under the MIT license [1]. Also its author is a top contributor to Julia ;). [1] https://github.com/JuliaMath/FFTW.jl

That MIT license only applies to the Julia wrapper code. The package downloads and dynamically links into an FFTW shared library, which means any code that uses it needs to be GPL if distributed as a whole.

Re: Julia 1.0

#182

Post by Accipitriform »

Svenskunganka wrote: post #168
ChrisRackauckas wrote: post #153

Earlier quoted context omitted.

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.

The blog mentions that Julia is supposed to be a general purpose language, and not a language built specifically for scientific computing. Is that wrong? The first impression does leave me thinking that using Julia for different programming domains like distributed internet-facing servers or web services is not something it was built for.

> The blog mentions that Julia is supposed to be a general purpose language, and not a language built specifically for scientific computing. Is that wrong?

No. Julia is a general purpose language that has so far been mainly focused on scientific and mathematical programming.

It's design is probably least friendly to the real-time programming domain (GC based) but it can apparently be used there as well:

http://www.juliarobotics.org/

I see an extremely bright future ahead for Julia!

Re: Julia 1.0

#183

Post by dnautics »

ur-whale wrote: post #90
stellalo wrote: post #81

Earlier quoted context omitted.

1-based indexing is a non-issue

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 started using elixir/erlang, which basically doesn't have indexing, ever. It's been a joy.

Re: Julia 1.0

#184

Post by SolarNet »

ur-whale wrote: post #164
goatlover wrote: post #125

Earlier quoted context omitted.

It's not any harder to get used to than using whitespace for blocks in Python, or having to end every damn statement with a semicolon in the C inspired languages.

>It's not any harder to get used to than using whitespace for blocks in Python, or having to end every damn statement with a semicolon in the C inspired languages. Strongly disagree. I can move from C to Python without a second thought and rewrite code from one to the other without even thinking. Having to rewrite an algorithm working on multidimensional arrays that was written with 0-based conventions to 1-based con…

Ok, then use the built in Julia features to use any offset you want inside your algorithm's code.

Compilers are pretty good about optimizing integer constants.

Re: Julia 1.0

#185

Post by dnautics »

ur-whale wrote: post #161
psychometry wrote: post #117

Earlier quoted context omitted.

If 1-indexing seems strange, you're probably not doing mathematical or statistical computing, so it's probably not the language for you.

I've done math and stats all my life. When I do sigmas in math, they go: i=0,i<n and very rarely i=1, i<=n unless the problem really is made simpler by the weird 1-based indices.

that's very bourbakian, but pretty much everyone else does 1..n, except for taylor series.

Re: Julia 1.0

#186

Post by marmaduke »

mlthoughts2018 wrote: post #84
taliesinb wrote: post #49

I have high hopes for Julia becoming the defacto open-source scientific language. Despite Python and R both having a massive head start, I'm willing to bet that talented engineers and scientists will be drawn to Julia to implement their next-generation frameworks owing to the powerful features that it offers. For example, the fact that an array of unions such as Array{Union{Missing,T}} is represented in memory as a m…

I am a machine learning library developer and I don’t share your feelings. For example the specific example you cite, I feel, should never be something scientists or engineers actively think about, only language implementers. Once you make that distinction, then whether you write it as a Cython module exposed in Python or you can use native language features to do it in Julia, nobody cares. It’s encapsulated away fro…

I see your comment grayed out, and I just want to chime in, as some who does a lot of numerical stuff (more than a decade, published stuff, support multiple lab research projects etc), I want to second this point of view. When it’s time to get real work done Python is more than good enough, and there’s plenty of strategies for acceleration where required.

And when I want Julia’s promise of fast loops, I use Numba. If all the effort gone into Julia had instead been spent on fixing remaining warts in Python workflow for science, we wouldn’t even havee this conversation.

Re: Julia 1.0

#187

Post by civility »

KenoFischer wrote: post #156
civility wrote: post #134

Earlier quoted context omitted.

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.

I understand the argument, but when the default disagrees with your override, there's almost always an impedance mismatch and some pain. It's like being left handed when 99% of the interfaces in the world assume you're right handed.

People argue that zero-based is incidental, and that 1-based is the right way because of it's long history in mathematics notation. I would argue that 1-based is incidental, and that zero-based is better most of the time for modern math and computer architectures.

Re: Julia 1.0

#188

Post by ChrisRackauckas »

mlthoughts2018 wrote: post #175
ChrisRackauckas wrote: post #97

Earlier quoted context omitted.

It's offering something completely different because of the compatibility, compile-time controls, and ability to fully interprocedurally optimize. http://www.stochasticlifestyle.com/why-numba-and-cython-are-...

The article you link is severely wrong about both numba and Cython. I frequently use Cython to quickly wrap calls to other C++ implementations of tools I want to try and have a working Python module in a matter of minutes, and I have almost no knowledge of C++. Modern numba can also do a lot more for huge scale projects than what the article suggests. Julia docs also seem very smugly proud of multiple dispatch and au…

The points that you mentioned are not relevant to what's in the article.

Cython fused types are required to be known at the package's compile time, and that's exactly the point that makes it less composible. Not requiring this is exactly the advantage of Julia which is demonstrated.

The article doesn't say Numba cannot do huge scale projects. It just talks about the difference in the compilation strategies. If you read that and think that it means Numba isn't suited for huge scale projects, then that's your interpretation of how Numba works, not an opinion directly stated by the article.

The article gives an easy way for you to demonstrate it wrong. You can show 10 lines of code where you send dual numbers and uncertainty objects through SciPy's ODE solvers to generate solutions with gradients and error bars. If Cython can do this, please show it.

Re: Julia 1.0

#189

Post by ur-whale »

dnautics wrote: post #185
ur-whale wrote: post #161

Earlier quoted context omitted.

I've done math and stats all my life. When I do sigmas in math, they go: i=0,i<n and very rarely i=1, i<=n unless the problem really is made simpler by the weird 1-based indices.

that's very bourbakian, but pretty much everyone else does 1..n, except for taylor series.

>that's very bourbakian

guilty as charged :)

Re: Julia 1.0

#190

Post by StefanKarpinski »

semi-extrinsic wrote: post #137
babahoyo wrote: post #99

Earlier quoted context omitted.

Many scientists might have mathematical ideas about how an operation should be done, but dont want to learn C++ to implement them. We create a division between scientists and programmers that hurts productivity.

Contrarian view: having a division between "general scientists" and "programmer scientists" is a good thing. I really don't miss the bad old days of scientists doing write-only code from a cobbled-together mess based on Numerical Recipes, leaving behind spaghetti C99 or F77 for the next post-doc, commenting out routines for version control; giving us papers with numerical analysis that's not even reproducible by the…

I can understand how one can reasonably hypothesize that. In some sense you can see Julia as one big social experiment in what happens when you do everything possible to blur the line between users and developers of a scientific (and, of course, also general) programming language by solving the two language problem and making the language for users and developers one and the same.

... and it's been wildly successful. Some of the most prolific and talented contributors to Julia and its ecosystem are scientists by day and brilliant programmers of all kinds—crazy meta programmers, compiler hackers, generational GC writers, etc.—by night (as they say). During the keynote last night before tagging 1.0, we went through the history of major features in Julia's development history, it became a running theme that so many of these contributions have come from people who are physicists, chemists, geologists, biologists, etc. So I'd say that Julia is strong evidence that breaking down the separation between scientific users and developers of scientific libraries is a good idea.

Post reply on HN