Re:Julia as a unifying end-to-end workflow language on the F...
by renox on Sunday November 19, 2023 @07:08AM
(#38331895)
Couldn't this kind of things be caught by type checking?
1-indexed vectors should be different type than arbitrary offset vector (implicitly convertible in one way only).
Re:Julia as a unifying end-to-end workflow language on the F...
by eigenspace on Sunday November 19, 2023 @07:30AM
(#38332056)
They are different types, but they share a common supertype (AbstractArray). AbstractArray includes thing like regular Array, and also a whole zoo of other array types (including OffsetArray).
The problematic code was incorrectly saying it worked on any subtype of AbstractArray, but was actually written assuming that the arrays were 1-based which is an invalid assumption.
What happened here is that julia has a package called OffsetArrays.jl which can be used to create arrays with arbitrary index offsets. Julia arrays start at index 1 (1-based indexing), but with OffsetArrays you could make 0-based arrays, or 10-based arrays or whatever you want.
There happened to be a bunch of code laying around which was older than OffsetArrays.jl and did things like
which implictly assumed that all abstract vectors could be indexed according to normal 1-based indexing rules. This created a lot of silent problems when people then went and fed offset arrays into functions that were using such incorrect indexing schemes.Instead, modern julia code that works on AbstractArray is supposed to be written using functions like eachindex, or axes, i.e.
though Julia's compiler is now smart enough that using @inbounds like this is typically unnecessary, since it can see that eachindex(v) can't produce an out-of-bounds index.