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

331–340 of 446 posts

Re: Julia 1.0

#331

Post by simonbyrne »

jacobolus wrote: post #329
simonbyrne wrote: post #325

Earlier quoted context omitted.

The other point is that remainder makes much more sense for floating point numbers, as it's exact. mod on the other hand is not, and is fiendishly difficult to get "right" (if that is even possible).

In what context do you use it? I use a “mod” operator all the time for floating point calculations, and have never come across a need for the other one. As one simple example, it is frequently useful to map floats into the range [0, 2 π ), but I have never once wanted to map positive floats into the range [0, 2 π ) while negative floats get mapped into (–2 π , 0] by the same code.

Well, I have indeed spent more time thinking about this than is probably healthy, but here are some nice edge cases to think about:

- https://github.com/JuliaLang/julia/issues/14826

    mod(-eps(), 4.0)
- https://github.com/JuliaLang/julia/issues/17415

    fld(1.0,0.2)
- https://github.com/JuliaLang/julia/issues/3127

    mod(1.0,0.1)
- https://github.com/JuliaLang/julia/issues/3104

    mod(0.95,0.01)
I'm pretty sure there are more issues.

re: mod 2pi, typically it is most accurate to reduce to (-pi,pi) (i.e. division rounding to nearest). Also to get it accurate you need fancy range reduction algorithms, hence julia has rem2pi https://docs.julialang.org/en/stable/base/math/#Base.Math.re...

Re: Julia 1.0

#332

Post by rrock »

civility wrote: post #317
KenoFischer wrote: post #306

Earlier quoted context omitted.

I can understand why you might get the impression, but I'd encourage you to try out julia and see that we're really quite good at using index-agnostic abstractions, so most code doesn't care what your arrays are indexed with. If a certain set of indices make sense in your domain (0-based for FFTs as you say, symmetric indices about the original for image filters, 1-based for just regular lists of things, etc), just u…

I'll (cautiously) take your word that this works transparently when I supply arrays as arguments to a library function. However, what does the library function return to me as arrays it allocates? What if I do an outer product of two arrays with different base indices? Whatever your answer, I suspect it is more cognitive overhead to remember than "always 1 based" or "always 0 based".

Not really. Imagine taking a rectangular region of interest from an image. With offset arrays, you can use the original indices if that suits you. I’d say that’s strictly better than using always zero based offsets.

Re: Julia 1.0

#333

Post by jacobolus »

simonbyrne wrote: post #331
jacobolus wrote: post #329

Earlier quoted context omitted.

In what context do you use it? I use a “mod” operator all the time for floating point calculations, and have never come across a need for the other one. As one simple example, it is frequently useful to map floats into the range [0, 2 π ), but I have never once wanted to map positive floats into the range [0, 2 π ) while negative floats get mapped into (–2 π , 0] by the same code.

Well, I have indeed spent more time thinking about this than is probably healthy, but here are some nice edge cases to think about: - https://github.com/JuliaLang/julia/issues/14826 mod(-eps(), 4.0) - https://github.com/JuliaLang/julia/issues/17415 fld(1.0,0.2) - https://github.com/JuliaLang/julia/issues/3127 mod(1.0,0.1) - https://github.com/JuliaLang/julia/issues/3104 mod(0.95,0.01) I'm pretty sure there are more i…

Without knowing the intended use case of the code, the edge case behavior in some of these cases is pretty meaningless. Different behavior might make sense in different applications, and in many applications the choice is largely irrelevant. Whichever one you choose someone who wants the other version will have to work around it.

These examples don’t really have much bearing on the general usefulness of “remainder” vs. “modulo” though.

Re: Julia 1.0

#334

Post by mlthoughts2018 »

ChrisRackauckas wrote: post #301
mlthoughts2018 wrote: post #242

Earlier quoted context omitted.

The first and second paragraphs under “Point 1” are specifically saying Cython & numba work just as well as Julia for single functions, then saying the problem where they are inferior to Julia is large code bases.

No, I say that Cython and Numba made an engineering tradeoff that reduces their performance and flexibility in exchange for the ability to compile their codes separately, whereas Julia needs to compile dependently. You are the one that is inferring that means it's inferior. There are cases where this ability to easily reduce compile time can be useful, and there are cases where the improved flexibility and performanc…

This is a quote from the link:

> “It's not hard to get a loop written in terms of simple basics (well okay, it is quite hard but I mean "not hard" as in "give enough programmers a bunch of time and they'll get it right"). Cool, we're all the same. And microbenchmark comparisons between Cython/Numba/Julia will point out 5% gains here and 2% losses here and try to extrapolate to how that means entire package ecosystems will collapse into chaos, when in reality most of this is likely due to different compiler versions and go away as the compilers themselves update. So let's not waste time on these single functions. Let's talk about large code bases. Scaling code to real applications is what matters. Here's the issue: LLVM cannot optimize a Python interpreter which sits in the middle between two of your optimized function calls, and this can HURT.”

You seem to be disingenuously recasting what’s written in the link to serve shifting purposes, to the point that I am skeptical you’ve even got a coherent claim here in your comments.

Re: Julia 1.0

#335

Post by StefanKarpinski »

et2o wrote: post #264
kgwgk wrote: post #177

Earlier quoted context omitted.

A binary package will be available in CRAN for a given platform/version only if it works (it passes all the tests). It seems that Julia lets you install a non-working package without any warning (you will probably get errors when you run it, but I guess it may also fail silently which is worse).

I was excited to try using Julia 1.0.0 today after a couple years since my last try and... couldn’t. None of the packages work with it yet. I guess I could go find an older version, but it seems like a problem that Julia will happily allow you to install a package it isn’t compatible with. What’s the point of the Pkg system then? CRAN’s model makes a lot more sense.

Many packages have declared them selves compatible with any future version of Julia... which is clearly a lie. These need upper bounds on their version compatibility, but that will take some time to propagate through the system.

Re: Julia 1.0

#336

Post by StefanKarpinski »

ontouchstart wrote: post #238
StefanKarpinski wrote: post #190

Earlier quoted context omitted.

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

I was watching live stream last night from the East coast and very impressed by the achievement by you scientists and grad students since 2012. https://arxiv.org/abs/1209.5145 As a former physicist, I have been through the Numerical Recipes/F77 stage myself two decades ago. In the age of Big Data and Machine Learning, there are many ways to harvest the creativities in people who are not trained as professional engine…

> I was watching live stream last night from the East coast and very impressed by the achievement by you scientists and grad students since 2012. https://arxiv.org/abs/1209.5145

Thank you, that's very kind of you! To be fair, Jeff, Viral, Alan and I had many collective decades of industry experience interleaved with an equal amount of academia by the time we wrote that paper. And of course the academics are rather suspicious about just how academic we really are.

> We need more crazy meta programmers.

Hear, hear!

Re: Julia 1.0

#337

Post by romwell »

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

Thanks for the great article.

An unexpected takeaway: Michael Chastain's time-traveling debugging framework, which he had in 1995, and which still reads like sci-fi from the future[1].

Alas, this quote will probably stay relevant for a while:

>[We keep] finding programming constructs, ideas and approaches we call part of “modern” programming if we attempt them at all, sitting abandoned in 45-year-old demo code for dead languages.

[1]http://lwn.net/1999/0121/a/mec.html

Re: Julia 1.0

#338

Post by marmaduke »

ChrisRackauckas wrote: post #299
tavert wrote: post #202

Earlier quoted context omitted.

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

SciPy solvers are mostly interfaces to existing established solvers, and I’ve not had any problems with them. We’ve also used PyDSTool without problem, and it appears to support Python 3,

https://github.com/robclewley/pydstool/blob/master/README.rs...

If you think these are poorly maintained you should see XPPAUT, a tool still quite widely used.

Re: Julia 1.0

#339

Post by marmaduke »

ChrisRackauckas wrote: post #300
marmaduke wrote: post #257

Earlier quoted context omitted.

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

No you can’t, at least, not if you want it work. This has nothing to do with Julia though and I didn’t say you can’t run AD over the solver but that that generally will not produce good gradient estimates unless the solver is written with AD in mind. DDEs are a mixed case where I’d expect some parts to be workable but not in general. Another example is the FFT, totally worthless to use AD.

Re: Julia 1.0

#340

Post by marmaduke »

ChrisRackauckas wrote: post #298
marmaduke wrote: post #230

Earlier quoted context omitted.

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.

What are user defined types that don’t require being defined?
Post reply on HN