Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Correctness and composability bugs in the Julia ecosystem

yuri.is

Post reply on HN
Print view View original

61–70 of 419 posts

Re: Correctness and composability bugs in the Julia ecosystem

#61

Post by wnoise »

sdfhdhjdw3 wrote: post #31
karmakaze wrote: post #11

Earlier quoted context omitted.

I was wondering if the 1-based arrays (and option to change index base) would factor into this. > OffsetArrays in particular proved to be a strong source of correctness bugs. The package provides an array type that leverages Julia’s flexible custom indices feature to create arrays whose indices don’t have to start at zero or one. Array indexing is such a core thing and I don't understand why anything mathematical or…

> Array indexing is such a core thing and I don't understand why anything mathematical or scientific would start with 1. Because that's how maths work? Literally everywhere in maths you count from 1, except in software engineering. That's why. I hope that clarified your confusion.

Starting with 0 is quite common in series, e.g. Taylor, Fourier, Chebyshev expansions, etc.

Re: Correctness and composability bugs in the Julia ecosystem

#62

Post by one-more-minute »

It might be useful to separate the issues that are "just" bugs from the problems that come with Julia's unusual level of composability. I have no idea if Julia has more bog-standard, local bugs – things like data structure problems or compiler faults – than other languages of comparable maturity and resources, but clearly the OP has bumped into several, which is frustrating.

The composition bugs – as in offsetarrays or AD – are a bit of a special case. In most languages package A will only work with package B if it's specifically designed to, and the combination will be explicitly developed and tested. That A and B can work together by default in Julia is really cool, but it also means that as you add new types and packages, you have a quadratically growing set of untested edges.

The canonical solution is strict interfaces. But Julia is laissez faire about those too (with some good reasons). Together this means that if A doesn't work with B as expected, it's not always easy even to assign fault, and both might be reluctant to effectively special-case the other. Program transformations (autodiff) compound this problem, because the default is that you promise to support the universe, and it's not easy to opt out of the weird cases.

I think it's absolutely right to celebrate Julia's approach to composition. I also hope new research (in Julia or elsewhere) will help us figure out how to tame it a bit.

Re: Correctness and composability bugs in the Julia ecosystem

#63

Post by harpiaharpyja »

tqaky wrote: post #19

Quoted post unavailable.

I'm guessing you've never used Python for a serious project before, because your statement is incorrect. Aside from the fact that Python is memory safe, my experience has been that it is far easier to avoid logic errors in Python than in C/C++.

Equivalent Python code is shorter and less noisy than C/C++, and Python makes it easier to create succinct and simple to use abstractions. The result is that code is far easier to audit. Furthermore, my experience has been that it is much easier to create unit and integration tests in Python, which means that people actually do it and/or test more comprehensively.

My experience has been that if the performance cost of Python is no object then there is a correctness benefit over C/C++ for a disciplined programmer. I suggest you gain some more experience with both languages before making an offhand comparison.

Re: Correctness and composability bugs in the Julia ecosystem

#64

Post by xdavidliu »

coldtea wrote: post #40
karmakaze wrote: post #11

Earlier quoted context omitted.

I was wondering if the 1-based arrays (and option to change index base) would factor into this. > OffsetArrays in particular proved to be a strong source of correctness bugs. The package provides an array type that leverages Julia’s flexible custom indices feature to create arrays whose indices don’t have to start at zero or one. Array indexing is such a core thing and I don't understand why anything mathematical or…

> Array indexing is such a core thing and I don't understand why anything mathematical or scientific would start with 1. Because starting with 0 is neither math nor array indexing in general. It's just how the base addresss of an array pointer memory block was referenced in C (and it spread from there). Which is why all math focused languages use 1-based (fortran, apl, matlab, r, mathematica, etc.)

> It's just how the base addresss of an array pointer memory block was referenced in C (and it spread from there).

There was also the famous 1-pager by Dijkstra: "Why numbering should start at zero"

https://news.ycombinator.com/item?id=777580

Re: Correctness and composability bugs in the Julia ecosystem

#65

Post by kllrnohj »

exyi wrote: post #22
ur-whale wrote: post #6

The examples provided feel more like bugs in various libraries than an actual problem intrinsic to Julia the language.

Yea, all are just bugs, not some intrinsic flaws in the language. Given Julia's goals (performance, abstractions, accessible to science people), it's understandable if they had slightly higher bug concentration than other (similarly sized) ecosystems.

The author's argument is that the bugs all share a pattern, and thus there is an intrinsic flaw. That doesn't necessarily mean the community wants to fix the intrinsic flaw, just like nobody is really interested in fixing the intrinsic memory safety flaws of C. But they shouldn't be denied as real risks, either, or a tradeoff of some kind.

Re: Correctness and composability bugs in the Julia ecosystem

#66

Post by xscott »

jjgreen wrote: post #34
davisoneee wrote: post #27

Earlier quoted context omitted.

I'll start by saying that I greatly prefer 0-based, and have used but 0- and 1-based indexing, but the choice is largely arbitrary. 0 makes sense as the '0-th offset' when thinking from a pointer perspective, but I often find when teaching, that 1-based comes more naturally for many students (the 'first' item). You mention mathematical or scientific work...but I often/mainly see enumerations (such as weights x_1, x_2…

Not for polynomial coefficient indices :-)

Or Fourier coefficients :-) Or pretty much anything where the index/subscript is related to the math itself.

Math textbooks and papers tend to use 1-based subscripts when it doesn't matter. It's hard to come up with examples where starting at 1 facilitates the actual math.

Re: Correctness and composability bugs in the Julia ecosystem

#68

Post by trenchgun »

wodenokoto wrote: post #21
ur-whale wrote: post #6

The examples provided feel more like bugs in various libraries than an actual problem intrinsic to Julia the language.

According to the article the problem is in the ecosystem, and partly the standard lib. Basically it doesn't matter if Julia the language is fine, if all the stats packages make wrong calculations. Then what is the point of Julia, if you have to rewrite all things? might as well use another language where you trust the result of the ecosystem, since it is the ecosystem you need in order to produce results.

All bugs mentioned had been quickly fixed: https://news.ycombinator.com/item?id=31397425

Re: Correctness and composability bugs in the Julia ecosystem

#69

Post by fluidcruft »

QuackingTheQ wrote: post #52

I've spent a lot of time developing large computational codebases in Julia, and I think the most insidious of these issues is a product of no formal way of enforcing interfaces. Using one of the common packages to build a trait system and add some sort of guarantee that all the right methods are implemented for a given trait simplifies maintenance dramatically. This doesn't catch mathematical bugs, but those crop up…

Could some of the need for interfaces be addressed by providing an extensive test battery for types of object? It seems like if something claims to be an implementation of a floating point number it should be possible to smash that type into every error ever found to uncover implementation errors.
Post reply on HN