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

291–300 of 446 posts

Re: Julia 1.0

#291

Post by pkofod »

ur-whale wrote: post #198
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…

Agreed. Even better if they had code snippets that highlights what makes the language cool (instead of the usual "Hello World").

what is "cool" is very person specific though. It's hard to fully appreciate multiple dispatch in 8 lines for example

Re: Julia 1.0

#292

Post by jacobolus »

Certhas wrote: post #281
dangom wrote: post #214

Earlier quoted context omitted.

This is very much a non-argument. Call the columns the 4th and 7th is as arbitrary as calling them the 3rd and the 6th. Again, 0-based indexing exists to fit a purpose: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW... In my opinion, reading `a = b[1:n-1]` hurts much more than reading `a = b[:n]`.

It's not arbitrary. It's English. In the list [apple, orange, tree] which element is orange? It's the second element. I have taught Python quite a bit, and I have gotten good at explaining 0 based indexing and slicing based on it. When I switched to Julia there was nothing to explain. And my code has about as many +/- 1s as before...

Just because it is our common convention in lay conversation doesn’t mean it isn’t “arbitrary”.

These spoken language conventions developed before there was an established name for “zero” or even a concept that “nothing” could be a number per se.

For similar reasons, we have no zero cards in our decks, no zero faces on a dice, no zero hour on our clocks, no zero year in our calendar, no zeroth floors in our buildings, East Asian babies are born with age one year, etc.

It’s only by another set of historical accidents that we have a proper 0 in our method of writing down whole numbers. Thankfully that one was of obvious enough benefit that it became widely adopted.

Re: Julia 1.0

#293

Post by orhmeh09 »

ur-whale wrote: post #277
orhmeh09 wrote: post #254

Earlier quoted context omitted.

If you look at ranks for worldwide sporting events , you’ll note that approximately none of them indicates first (zeroth ?) place with a 0. Can you give an example of a place where education at early childhood level is carried out as you claim ?

>ranks for worldwide sporting events You're right ... sporting events ... how could I have not included that very scholarly pursuit of engineers, scientists and programmers in my analysis. I'm not trying to claim that 0-based is better than 1-based. I'm just trying to point out that outside of the fairly limited crowd who spend their workday in things like Matlab and R, the vast majority of coders in the world in 201…

Since you mentioned children learning to count, I tried to find a general, widely known case that would be as applicable around the world, and I provided a study examining why 0 can be a difficult concept (which humankind developed very recently). The number of toddlers who are engineers in the sense I think you’re talking about is approximately zero, too.

Furthermore, the widespread mathematical / scientific computing languages have used 1-based from FORTRAN through Matlab and Mathematica. Statistical papers are published with accompanying R code , very rarely with Python. If 1-based indexing is too hard to get used to, you may not be in the target audience. Anecdotally, I used C and Python well before started R, and I’m not really the smartest bulb in the box. I was annoyed for about a week. If you have the knowledge of what you will use Julia for, this hurdle seems very minor in my opinion.

Re: Julia 1.0

#294

Post by j605 »

swdunlop wrote: post #210

Julia 1.0 will be rough until major packages have caught up with the deprecations introduced in 1.0 and 0.7. 1.0 does not tolerate these deprecations, while 0.7 will warn about them. This makes a poor first day impression for new users who expect Plots.jl, IPython.jl, Juno.jl or other prominent packages in 1.0. The package maintainers are scrambling to catch up. I recommend using 0.7 for a couple weeks until the comm…

TBH even jupyter broke due to recent python update but people are not jumping on python, https://github.com/jupyter/jupyter_console/issues/163

Re: Julia 1.0

#295

Post by civility »

simonbyrne wrote: post #283
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.

Well for FFTs you really want periodic indices. Luckily Julia has those too: https://github.com/JuliaArrays/FFTViews.jl

I do a lot of FFTs for a living - I really want my zeroth frequency in my zeroth bin. Negative indices (as done by Python and other places) are nice though.

This points to another example where 0-based should be preferred. When doing modulo arithmetic, 0..N-1 mod N gives 0..N-1, but 1..N mod N puts the zero at the end. I also cringe at languages where -1 mod N does not equal N-1.

Re: Julia 1.0

#296

Post by jacobolus »

civility wrote: post #295
simonbyrne wrote: post #283

Earlier quoted context omitted.

Well for FFTs you really want periodic indices. Luckily Julia has those too: https://github.com/JuliaArrays/FFTViews.jl

I do a lot of FFTs for a living - I really want my zeroth frequency in my zeroth bin. Negative indices (as done by Python and other places) are nice though. This points to another example where 0-based should be preferred. When doing modulo arithmetic, 0..N-1 mod N gives 0..N-1, but 1..N mod N puts the zero at the end. I also cringe at languages where -1 mod N does not equal N-1.

Yes, people should never use “mod” or % as a synonym for “remainder”. It is horrible.

For any language with a mod operator, a mod b should always be equal to (a + k×b) mod b for any integer k.

Breaking this invariant makes the mod operator useless in pretty much every application I ever have for it. In e.g. JavaScript I need to define a silly helper function like

    mod = (x,y) => x%y + y*(x%y && x>0^y>0)
And then remember to never use the native % operator.

Re: Julia 1.0

#297

Post by renox »

jebej wrote: post #148
renox wrote: post #80

Earlier quoted context omitted.

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

You can use whatever start index you like: https://docs.julialang.org/en/stable/devdocs/offset-arrays/#... For a pre-baked solution: https://github.com/JuliaArrays/OffsetArrays.jl

The problem is the default behaviour: in Ada you can use whatever you want, in Julia the default is 1-based which is quite controversial.

Re: Julia 1.0

#298

Post by ChrisRackauckas »

marmaduke wrote: post #230
johnsea wrote: post #203

Earlier quoted context omitted.

> And when I want Julia’s promise of fast loops, I use Numba. This only works (easily) as long as you don't have user-defined types > 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. Python is too dynamic, you cannot just fix remaining warts. From Julia documentation I know that Julia language has been designed…

Numba has user defined types, https://numba.pydata.org/numba-doc/dev/user/jitclass.html No one intends to fix Python but it’s straightforward to do things like Numba: use a decorator to read out the AST for a function, reimplement it however you like and pass back the compiled function, and document the semantics.

But you have to define the types for them to work. That's exactly the problem and that's what Julia has already solved.

Re: Julia 1.0

#299

Post by ChrisRackauckas »

tavert wrote: post #202
celrod wrote: post #200

Earlier quoted context omitted.

I think it is easier to write fast, complicated code in Julia than in C, C++, or Fortran. Not just the syntax, but because of great support for generic code by default and metaprogramming making it relatively simple to write code to generate the code you actually want for any given scenario. Interactive benchmarking and profiling are a boon too. An example of the value of generic code is that forward mode AD is extre…

The reason I ran away from Julia and don't plan on ever using it again, and don't recommend anyone use it outside of academia, is that so much of the community is made up of grad students. So you get a lot of research code and people who have never been professional programmers maintaining most of the ecosystem. Julia Computing is largely made up of people they've hired from the community straight out of grad school.

SciPy's ODE solver doesn't have a stable contributor who contributes more than than about once a year even though it has many long standing issues, and PyDSTool hasn't had a commit in 2 years and doesn't work on Python 3 (and most of pycont is incomplete...). R's deSolve isn't even in a repository you can track and still hasn't fixed their DDE solver issues even though they directly mention in the docs how it's incorrect. So it's not like other open source software has strong maintenance structures....

Re: Julia 1.0

#300

Post by ChrisRackauckas »

marmaduke wrote: post #257
celrod wrote: post #249

Earlier quoted context omitted.

It'd probably be a lot easier to debug something somewhere in the Julia stack, than in the C/C++/Fortran code that many R libraries run through. My point with the rewrite was not garbage in, garbage out. It was that even though the original R code was using a library written in C, that library had to call a function he wrote in R millions of times. That R function being inherently slow is part of the problem. (The ea…

Optimization (or any gradient based algorithm) is a good use case for AD, but I don’t see why Julia’s approaches are any better than Python’s, eg autograd, theano, pytorch etc. And sure that wouldn’t work with arbitrary Cython modules because Cython was designed as a Pythonic syntax over the Python C-API, and it just happened to become popular for numerical work. I don’t think that’s a strong argument, though, becaus…

>And sure that wouldn’t work with arbitrary Cython modules because Cython was designed as a Pythonic syntax over the Python C-API, and it just happened to become popular for numerical work.

>I don’t think that’s a strong argument, though, because anything small enough to be usable with AD can be rewritten without too much time lost, whereas those massive Fortran routines with iterative algorithms wouldn’t produce useful gradients in any language.

No. In Julia you can just stick the entire delay differential equation solver into the AD functions and get a gradient for parameter estimation. Saying you cannot use an arbitrary Cython code is a limitation, and saying you cannot put a random large code into AD is a limitation. It wouldn't be an issue if these weren't already solved problems, but having a performant software with simple and available AD is not something that's unreasonable anymore. If you use Julia, it's just something you can expect to work.

Post reply on HN