Earlier quoted context omitted.
I'm using Julia (because of the hype) to prototype out some numerical optimization stuff. There is a million functions for reshaping multidimensional arrays. The syntax is uncannily like Matlab: retrieving the last element of an array with `[end]`, indexing into a collection with an array of booleans, element-wise versions of operators prepended with dot, etc. However, I keep running into niggling corner cases that k…
For the last thing, is this what you want? https://github.com/JuliaArrays/PaddedViews.jl There may be other packages or methods for doing the other things you want. I’d think that broadcasting over a NamedTuple would iterate over the key => value pairs, but I haven’t tried it.
Julia adoption keeps climbing
241–250 of 309 posts
Re: Julia adoption keeps climbing
#242Python has a battle-tested, humongous standard library, and a rich ecosystem. It is easy to learn and it's great at gluing every day stuff. Data scientists like it, engineers like it, even the cashier at Lidl likes it. I can see how Julia may challenge Python for academic use, but challenging Python in 2021 for industrial use is no joke.
Use it then: https://github.com/JuliaPy/PyCall.jl
Re: Julia adoption keeps climbing
#243Earlier quoted context omitted.
As sibling posts have pointed out, you can do all of those things: 1. You can trivially write a `getproperty` method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it. 2. You can broadcast over the fields of a `NamedTuple` by defining appropriate methods. Again, it's type piracy, so take that into consideratio…
I meant literally this: julia> (x = 1, y = 2) .+ (x = 1, y = 2) ERROR: ArgumentError: broadcasting over dictionaries and `NamedTuple`s is reserved
julia> Base.broadcasted(f, x::NamedTuple, y::NamedTuple) = "my custom method!"
julia> (x=1, y=2) .+ (x=1, y=2)
"my custom method!"Re: Julia adoption keeps climbing
#244I tested my well-optimised R code and saw only 3x to 10x performance gain. That's still not substantial enough currently to migrate a whole code base, in particular given that the libraries are also still not mature enough. The research group I'm working with also have no interest in adopting anything new, In fact most of our code is still in FORTRAN so that is something I would be more interested in migrating to Jul…
Re: Julia adoption keeps climbing
#245Earlier quoted context omitted.
Agreed on error handling actually. It doesn't quite have the feel that it should in a modern language. I think error handling and lifetimes/mutability are two of the top things we're looking at for a fundamental remodel in 2.0.
What about traits or multiple inheritance?
Re: Julia adoption keeps climbing
#246Earlier quoted context omitted.
I meant literally this: julia> (x = 1, y = 2) .+ (x = 1, y = 2) ERROR: ArgumentError: broadcasting over dictionaries and `NamedTuple`s is reserved
Stefan's point was that you are free to commit type piracy and make this do whatever you want julia> Base.broadcasted(f, x::NamedTuple, y::NamedTuple) = "my custom method!" julia> (x=1, y=2) .+ (x=1, y=2) "my custom method!"
Re: Julia adoption keeps climbing
#247Can anyone recommend some good resources to learn Julia? I am hoping there is something akin to the Rust Book [1] since watching youtube videos is too slow and the exercism option listed on the website is too cumbersome. [1] https://doc.rust-lang.org/book/
This might be helpful: https://benlauwens.github.io/ThinkJulia.jl/latest/book.html
I'm a bit surprised julialang.org only links to a the oreilly store page. Seems like you would want to call attention to a resource like this.
Re: Julia adoption keeps climbing
#248The comparison between different languages gets tiring when it focuses on making a black-and-white statement like "Julia is better" or "Python is better" and "x is never going to overtake y". Yes, Python has many more libraries thanks to it being much older than Julia, same for R. But at the same time, Julia can be used for impressive work that R/Python struggle with and which only seem solvable in these languages be…
Back in the mid-90's Java was the new hotness, and it probably made problems that required 100+ lines of C easier, but it's not still full of above-average programmers, as any language/ecosystem that achieves success will inevitably regress to the mean.
Re: Julia adoption keeps climbing
#249Earlier quoted context omitted.
Urg that website is so incredibly out of date. Julia has amazing things for autodiff. But like not the things listed on that website. Also python is still doing great with Jax and PyTorch.
I linked to the website (which was updated in May, but its contents could do with more work) because it has examples of how well the suite fits together. I don't know much about Jax. I've seen competent benchmarks showing an order of magnitude benefit for using ReverseDiff from the AutoDiff suite over Autograd, which is what Pytorch uses for reverse-mode autodiff
It really should be updated to have basically the content of this thread https://discourse.julialang.org/t/state-of-automatic-differe...
Re: Julia adoption keeps climbing
#250Earlier quoted context omitted.
Stefan's point was that you are free to commit type piracy and make this do whatever you want julia> Base.broadcasted(f, x::NamedTuple, y::NamedTuple) = "my custom method!" julia> (x=1, y=2) .+ (x=1, y=2) "my custom method!"
And as the phrase "reserved" in the error message indicates, it will likely be given a meaning once all the ramifications of doing so are worked out and the best choice of meaning is decided upon. If you're impatient and don't want to wait for that, define it to do what you want. Your code won't even break when it is given an official behavior since your method will overwrite the built-in one.