Live data from Hacker News

Julia 1.9

julialang.org

201–210 of 216 posts

Re: Julia 1.9

#201

Earlier quoted context omitted.

You can use CondaPkg.jl ( https://github.com/cjdoris/CondaPkg.jl ) to setup Python dependencies with version control. I haven't played with it too much but it seemed to work out for what I tried. Indeed the reason why I haven't had too many test cases is because in SciML we removed all Python dependencies since they were the main source of instability. PyDSTool.jl, FEniCS.jl, SymEngine.jl (through ParameterizedFuncti…

Is it fair to say that it is your career to rewrite code in Julia to write academic papers about julia?

Most of my time isn't academic or writing code. Most of it is focused on enhancing algorithms to achieve what's required for new methods to work deployed in production environments such as the Pumas clinical pharmacology work, and now working on what's required to get scientific machine learning point-and-click GUI ready. I always leave a little bit of time in mornings and weekends though for some coding, and a little bit a day goes a long way after years.

I stay away from code rewrites like the plague, which is why SciML maintains so many wrapper packages. It's less work and if there's nothing new then rewriting is thankless work. Unless we have some kind of angle for something new in the algorithm, we just recommend someone use the same old wrappers (for instance, IDA with fully-implicit DAEs). We won't beat the C/Fortran code without something new. However in most areas there's lots of interesting research to be done. I could "sabbatical as an academic" and spend the next 3 years just improving explicit Runge-Kutta methods: those for example are probably still 4x away or so from what I think is theoretically possible, but that's not going to happen any time soon since we have some real applications to focus on.

Those package deprecations mentioned above were deprecated by community efforts (BifurcationKit.jl replaced PyDSTool wrappers and was done by Romain Veltz, FEniCS wrappers were largely replaced by Gridap, and SymEngine was replaced by Symbolics which is largely the work of one of the Julia Lab PhD students Shashi). Even those had a largely new element to them though, with BifurcationKit focusing a lot on recent algorithms that other bifurcation software don't have (like the deflated Newton methods), and Shashi's Symbolics.jl work focusing on generality of term rewriting systems to allow for alternative algebras.

Re: Julia 1.9

#202

Earlier quoted context omitted.

Not as frequently. Having a broken release for a programming language is also bad practice.

Look at the backlog of issues in their GitHub for backports. You'll see detailed lists of reported and fixed breakages. The lists aren't small... Now go on to imagine the ones people don't report and instead patch and fix them locally. We aren't even talking about Julia code fixes, often these involve the C that creates it and are a nightmare to diagnose. I can't reply to your post unfortunately the thread is too lon…

This is the list of bugs fixed in the upcoming Matlab release:

https://www.mathworks.com/support/faq/pr_bugs.html

Just look at the first one: "In certain cases, pointAt method of satellite scenario Satellite class interprets Euler angle inputs in radians rather than degrees"

Your expectations are completely unrealistic.

Re: Julia 1.9

#203

Earlier quoted context omitted.

Cult? That's a very bad take. It's a tool, great for some stuff, rough edges here and there. People invest huge amount of effort fixing Python's shortcomings (pyspark, tf, jax, mojo) requiring a completely different way of thinking modulo the syntax. And nobody is talking about the "cult of the snake"

It's not culty to make packages for a language. It is culty to work 12 hrs a day to appease Julia computing for free to have your work taken renamed and offered to the community with different names on the authors list.

This is a bold statement. Can you provide references?

Re: Julia 1.9

#204
post #151

Earlier quoted context omitted.

I run in production several Julia projects and I honestly can't say I know what you are referring to. I do use some libraries through PyCall. This is a relatively frequent source of trouble, with libraries breaking because of 3rd party dependencies, behaviour changing, or even somehow installation suddenly stops working. This all happens in the python side, to the point that I am currently replacing all the libraries…

So much for solving the 2 language problem. Everytime I ended up in a similar situation the Julia code was rewritten either by me or someone else in c++ for practical/performance reasons. Hope you consider the same. The libraries for doing mathematics in C++ are surprisingly good and you might be surprised to find how easy parallel processing and fine tuning is in c++. In some ways it's less cognitive load than Julia…

My problem is not with Julia, my problem is with the Python ecosystem and its dependency management. Not sure how you can read what I wrote and reach that conclusion.

Re: Julia 1.9

#205

Earlier quoted context omitted.

>I work for AWS; these are the definitions we use, more or less. you're just being asinine - we're literally talking about binary code that's never seen by anyone that doesn't compile from source and goes digging around in the build dir - how could you possibly call that code "transparent" in any sense of the word? are blob drivers also transparent according to these "AWS" definitions? >I was specifically referring t…

> PyTorch (and Chainer) eschew this tape; instead, every intermediate result records only the subset of the computation graph that was relevant to their computation. This means PyTorch users can mix and match independent graphs however they like, in whatever threads they like (without explicit synchronization). An added benefit of structuring graphs this way is that when a portion of the graph becomes dead, it is aut…

homie it is literally the first sentence in the quoted paragraph

>PyTorch (and Chainer) *eschew* this tape; *instead*, every intermediate result records only the *subset* of the computation graph that was relevant to their computation.

>Either I am an absolute fucking moron

you said it not me

Re: Julia 1.9

#206

Earlier quoted context omitted.

> PyTorch (and Chainer) eschew this tape; instead, every intermediate result records only the subset of the computation graph that was relevant to their computation. This means PyTorch users can mix and match independent graphs however they like, in whatever threads they like (without explicit synchronization). An added benefit of structuring graphs this way is that when a portion of the graph becomes dead, it is aut…

homie it is literally the first sentence in the quoted paragraph >PyTorch (and Chainer) * eschew* this tape; * instead* , every intermediate result records only the * subset* of the computation graph that was relevant to their computation. >Either I am an absolute fucking moron you said it not me

Did I ever claim that it created a tape?

If my comments implied that, then I am sorry for miscommunicating, but by calling it "dynamic" I meant that there is no compiling of a tape or tracking it as done with TF and the likes.

> I nternally, a Variable is simply a wrapper around a Tensor that also holds a reference to a graph of Function objects. This graph is an immutable, purely functional representation of the derivative of computed function; Variables are simply mutable pointers to this graph (they are mutated when an in-place operation occurs; see Section 3.1). A Function can be thought of as a closure that has all context necessary to compute vector-Jacobian products. They accept the gradients of the outputs, and return the gradients of the inputs (formally, the left product including the term for their respective operation.) A graph of Functions is a single argument closure that takes in a left product and multiplies it by the derivatives of all operations it contains. The left products passed around are themselves Variables, making the evaluation of the graph differentiable.

Please explain how it doesn't hold a graph when it literally says it is holding one, dynamically created and kept alive via ref counting.

I am losing my mind here.

Re: Julia 1.9

#207
post #10

Earlier quoted context omitted.

They probably want to say "why is this post necessary for every Julia release?".

Why not? If users didn't want to see it they wouldn't upvote it. So people want to see these posts. As simple as that. Why do we need this discussion on almost every Julia post that gets voted to the front page?

Yep, I'm all up for it. Just replying to parent.

Re: Julia 1.9

#208

Earlier quoted context omitted.

Not as frequently. Having a broken release for a programming language is also bad practice.

Look at the backlog of issues in their GitHub for backports. You'll see detailed lists of reported and fixed breakages. The lists aren't small... Now go on to imagine the ones people don't report and instead patch and fix them locally. We aren't even talking about Julia code fixes, often these involve the C that creates it and are a nightmare to diagnose. I can't reply to your post unfortunately the thread is too lon…

Other languages don't have that? CPython has almost 7k issues open atm. GHC has 5k. Again, FUD.

Re: Julia 1.9

#209

Earlier quoted context omitted.

I offered you a simple test you can perform so you can trust yourself after performing it.

You offered nothing besides FUD. I regularly read the forums and I don't know what you're referring to.

Get involved in the community. You'll see. This isn't FUD. It's observations of someone who has been very active in the community since well before the 1.0 release.

Re: Julia 1.9

#210

Earlier quoted context omitted.

It's not culty to make packages for a language. It is culty to work 12 hrs a day to appease Julia computing for free to have your work taken renamed and offered to the community with different names on the authors list.

This is a bold statement. Can you provide references?

Sure graphs.jl used to be lightgraphs.jl. rumor has it the author was bullied out of the community for their personal beliefs which had nothing to do with graphs or programming. Then the Julia crew took the project and sunset the lightgraphs guys work. There are other cases of stuff like this happening but I'm too lazy. Just go ahead spend a few years in the community contributing, good times ahead. Keep in mind, if you aren't paying for the product you are the product.
Post reply on HN