Zero-starting vectors

[Francesco Bonazzi]

Hi, I was wondering whether it is possible to define a zero-starting vector instead of one-starting vectors, as usual in Julia.

In particular, I am considering its usage in modern physics: in relativity, classical quantities represented by 3-vectors (vectors with three components), become 4-vectors, by the addition of a time-like component. 3-vectors are indexed from 1 to 3, while 4-vectors are indexed from 0 to 3, so that dropping the first (zero-indexed) component, you get a three-vector.

Is there a way to represent both forms of array in Julia?

[Tim Holy]

On Sunday, November 17, 2013 07:39:07 AM Francesco Bonazzi wrote:
> Hi, I was wondering whether it is possible to define a zero-starting vector
> instead of one-starting vectors, as usual in Julia.

> [snip]

> Is there a way to represent both forms of array in Julia?

Easily, just define a new type and then define

getindex(a::ZeroOffsetVector, i) = a[i+1]

[Tim Holy]

Sorry, in the rhs it needs to refer to the data inside a, not a itself.

On Sunday, November 17, 2013 07:39:07 AM Francesco Bonazzi wrote:

[Jiahao Chen]

This needs to be a talking point somewhere.

"Are you like Dijkstra and don't like 1-based indexing? Just define your own type and carry on!"

[John Myles White]

Well, we don’t really want people to do this because it will lead to problematic fractures in the community if a subset of people start publishing code that uses 0-basex indexing. It’s cool if people do that for themselves, but it’s really bad if they start sharing it with others.

— John

[Jiahao Chen]

That's a fair point. It's nice to have the flexibility though, especially when it expresses a particular application nicely.

[Miles Lubin]

On the crazy side of things, for JuMP I implemented an array class that is indexable over arbitrary ranges and by arbitrary sets. For ranges, -10:10, for example, is supported and indices will be efficiently translated. A macro is used to generate the required type at compile time, so that indexing over each dimension is as efficient as possible: https://github.com/JuliaOpt/JuMP.jl/blob/master/src/JuMPDict.jl.

Example usage:

m = Model()
myset = [:foo,:bar]
@defVar(m, x[-1:1,myset])
x[-1, :foo] # works

[Francesco Bonazzi]

On Sunday, November 17, 2013 7:31:25 PM UTC+1, Jiahao Chen wrote:

That's a fair point. It's nice to have the flexibility though, especially when it expresses a particular application nicely.

Yes, my example is simple. In special relativity coordinates are represented by 4-plets: (t, x, y, z), this is due to the fact that time is not the same for every observer. When the speeds are low (far below the speed of light), relativity approximates to Newtonian mechanics, so time is the same for everyone, and the t is dropped, so the coordinates are (x, y, z). In order to have the same indices point to the same coordinate, the 4-vector has zero offset, while the 3-vector has 1-offset.

[Kjetil brinchmann Halvorsen]

?Is there some good reason to not use the fourth coordinate for time?
(just curious)

Kjetil

[Tracy Wadleigh]

Alternately, define an immutable type(s) with field names x,y,z,(t). Could be faster than the built-in Vector for small dimensions. (t,x,y,z) also admits a meaningful quaternion multiplication in relativity, no? Maybe use an existing quaternion implementation, or write your own?

[Francesco Bonazzi]

On Sunday, November 17, 2013 9:51:23 PM UTC+1, Kjetil brinchmann Halvorsen wrote:

?Is there some good reason to not use the fourth coordinate for time?
(just curious)

To keep compliance with textbooks. This way, the indexing is the same as in textbooks.

[Stefan Karpinski]

I think that's a pretty valid reason – and is the reason for 1-based indexing in Julia in the first place. You may want to create your own space-time coordinate type with .t, .x, .y, and .z fields. Julia arrays are pretty low-overhead, but a custom type of fixed size will have much less overhead. You should definitely also make it immutable since points in space-time are not containers of values, but rather are themselves values. You can easily make your type support indexing by 0-3 as well as allowing access by field name.

[Jason Riedy]

Folks may want to check Chapel (chapel.cray.com) for another
idea. Arrays are associated with domains, and those define the
indexing. Array slices maintain their original indices, etc.

That last part makes things interesting. Code cannot necessarily
expect 0-based or 1-based indexing, so there's less of an issue
when people work differently. Code can shift the indices
explicitly to what it expects, however.
--
Jason

[Pablo Winant]

For a slightly different usecase, I have used a macro that rewrites all array indexing [i] as [i+1] in a limited scope. From a user perspective, the code inside the macro can be written with zero-based indexing. I used it as a temporary device to quickly port python code. The nice part of it is the fact that it can be applied to a part of a file, without modifying the objects that are returned outside of it that are still 1-based.

There are probably many disadvantages to it and I don't know how robust the macro is, but somebody want to have a look, here it is: https://gist.github.com/albop/7525675 .
When looking at the other thread about droping singleton dimensions, I considered the idea of extending it to some kind of numpy-compatibility context, but I'm not sure it's such a good idea.

Pablo

[John Lynch]

The concern about fracturing based on implementing 0 based and 1 based arrays seems to me to be very valid.  I'm also enjoying 1 based arrays after moving from Python but it does present an issue when migrating code.

I wonder if the best idea might be to acknowledge the issue but resolve it by tidying up Pablo's approach so that a macro could be used on "loosely adapted" python code to overcome the array adaptation issues (zero based and inclusive to exclusive slicing)?

This would seem to avoid fracturing Julia while easing migration from Python.

[Stefan Karpinski]

I actually suspect that lexically scoped zero-based indexing like Pablo is describing is ok. The main issue is when the index base is scoped dynamically globally or by object. There are certainly codes where it would be convenient to use zero-based indexing in a local scope.

[John Myles White]

There are certainly cases in which local zero-based indexing. (The original idea behind this thread is probably the best example I’ve ever seen.)

But maybe we can do more to make porting algorithms over easier? This is part of what I like about functions like mod1 and fld1: they let you do all the tricks you learn to do with zero-based indexing while working with one-based indexing.

— John