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

71–80 of 446 posts

Re: Julia 1.0

#71

Post by ChrisRackauckas »

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…

Most of these things are just packages. Just install FFTW.jl to get that FFT. https://github.com/JuliaMath/FFTW.jl

Julia's Base is for the language, not for every little detail so this is all handled by the package ecosystem.

Re: Julia 1.0

#72

Post by ChrisRackauckas »

creativeembassy wrote: post #67
jordigh wrote: post #55

Earlier quoted context omitted.

And Matlab and Octave in turn inherited it from Fortran, which inherited it from classical numerical analysis. One-based indexing has a good, long history.

To use a silly example... can I finally realize my dream of two-based indexing?

Yes. And 1.5-based indexing, though I would recommend using rational numbers instead of floating point numbers for this one.

Re: Julia 1.0

#73

Post by kgwgk »

peatmoss wrote: post #62
Q6T46nT668w6i3m wrote: post #44

Earlier quoted context omitted.

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…

> 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…

> the technical reason we started counting arrays at zero is that in the mid-1960’s, you could shave a few cycles off of a program’s compilation time on an IBM 7094. The social reason is that we had to save every cycle we could, because if the job didn’t finish fast it might not finish at all and you never know when you’re getting bumped off the hardware because the President of IBM just called and fuck your thesis, it’s yacht-racing time.

http://exple.tive.org/blarg/2013/10/22/citation-needed/

Re: Julia 1.0

#74

Post by _0w8t »

Q6T46nT668w6i3m wrote: post #54
_0w8t wrote: post #11

Earlier quoted context omitted.

This is my thinking as well. Python is nice to glue things, but doing high-performance math is not its strength. Things like GIL should be addressed long time ago, but it seems it is so fundamental to make things work in Python that I have big doubts that it will ever be addressed.

I agree that the GIL has become a problem for a variety of high-performance tasks, but, I’m curious, what kind of problems have you encountered with numerical computation? I contribute to both NumPy and TensorFlow, two libraries with different processing models, and I don’t see any obvious area where removing the GIL would provide substantial benefits. However, I’ll readily admit that I don’t think about this too oft…

numpy wiki summaries that well [1]. Too many things especially with complex math cannot run in parallel unless one spends a lot of time on workarounds.

One starts with quick and dirty solution, makes it work on a small dataset and then struggle to make it utilize at least 4 cores to cut running time with more realist datasets. Surelly I can code numerical calculations in C++, but then the code cannot be maintained by python-only guy. So I hope that Julia or anything else with better parallel support replaces Python for scientific calculations when scaling quick and dirty solutions is straightforward.

[1] http://scipy-cookbook.readthedocs.io/items/ParallelProgrammi...

Re: Julia 1.0

#75

Post by stabbles »

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

Re: Julia 1.0

#76

Post by ViralBShah »

ChrisRackauckas wrote: post #71
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…

Most of these things are just packages. Just install FFTW.jl to get that FFT. https://github.com/JuliaMath/FFTW.jl Julia's Base is for the language, not for every little detail so this is all handled by the package ecosystem.

Also those bindings were developed by Steve Johnson himself!

Re: Julia 1.0

#77

Post by [deleted] »

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…

[deleted]

Re: Julia 1.0

#78

Post by lewis500 »

Tarrosion wrote: post #61

Since this is currently on top of HN and not everyone knows of Julia, a few thoughts on Julia from a very-contented-but-hopefully-rational user: - Julia is by far my favorite language. (I've also written significant code in Java, C++, and Matlab and small projects in Python, Mathematica, R.) - Julia is my favorite because it is super expressive but also fast. You don't have to make (big) compromises. There's a great…

> Because Julia is fast and expressive and extensible, in Julia everything can be Julia and not a mashup of other languages. I've been doing some work in Python recently, and it's painful to have Python lists, numpy arrays, Pandas series, and so forth.

This is exactly what I like about Julia. Even though getting started in Julia was tough (esp the older versions), once you get off the ground Python starts to seem like a very hard language, in that Python requires you to use these special libraries to run fast code. In Julia, the most obvious way to do something (e.g., for loops) is perfectly fine.

The main thing Julia lacks, for me, is an equivalent to Pandas. The DataFrames library lacks many very useful features of Pandas. But I am sure someone will tackle that.

Re: Julia 1.0

#79

Post by peatmoss »

kgwgk wrote: post #73
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…

> the technical reason we started counting arrays at zero is that in the mid-1960’s, you could shave a few cycles off of a program’s compilation time on an IBM 7094. The social reason is that we had to save every cycle we could, because if the job didn’t finish fast it might not finish at all and you never know when you’re getting bumped off the hardware because the President of IBM just called and fuck your thesis,…

Wow, I hadn’t seen this before. The history of this feud goes back before C. Thank you for a fascinating read!

Re: Julia 1.0

#80

Post by renox »

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…

> I initially defended the choice, but I now agree that 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

Especially since it would have been very easy to 'do it like Ada' and allow any start index by default (I have use Lua and it's really annoying to use an extension language with 1-index when the base language is 0-indexed)

Post reply on HN