9 ms·
what good is philosophy if you choose arrays based on 1? https://groups.google.com/forum/?hl=en#!topic/julia-dev/tNN72FnYbYQ https://groups.google.com/forum/?hl
by spot 8y ago
what good is philosophy if you choose arrays based on 1?
https://groups.google.com/forum/?hl=en#!topic/julia-dev/tNN72FnYbYQ https://groups.google.com/forum/?hl=en#!topic/julia-dev/tNN7...
- baldfat 8y agoSo does: APL, AWK, COBOL, Fortran, Lua, Mathematica, MATLAB, R, Smalltalk, Wolfram Because it is Mathmatics and have 1 be based on 0 makes no sense, you then have to switch between the two and it is easy to make a mistake. This is why I don't use Python and Pandas. I got burnt once and that was enough and switched to R. Sadly we are stuck with 0 based array in programming and due to a historical issue.
- pjmlp 8y agoYou have forgotten Algol, PL/I, Pascal, Oberon, Oberon-2, Active Oberon, Component Pascal, Mesa, Mesa/Cedar, Modula-2+, Modula-3, Eiffel, Basic,... Although in Wirth inspired languages, actually the indexes are flexible, but by convention 1 gets used.
- nadam 8y ago0 based arrays is objectively the preferred way for me and not for historical reasons. I write a lot of low level graphics algorithm stuff, and 1-based arrays would complicate index arithmetic. like now with everything 0 based having something like: arr[offset1 * 32 + offset2] would be the following if all my offsets would be 1-based and arrays would be 1-based: arr[(offset1 -1) * 32 + offset2] which is pretty arbitrary...
- syockit 8y agoYou could reshape it (https://docs.julialang.org/en/v1/base/arrays/#Base.reshape https://docs.julialang.org/en/v1/base/arrays/#Base.reshape). But if you're interfacing with libraries written with C interface you'd still have to subtract for both offset1 and offset2.
- baldfat 8y agoHistorically 0 based is for low level languages. 0 based makes sense for C. My issue is higher level languages Python, Java, C# there is plenty of things that just are complicated and doing arrays off 0 is one of them. Doing data science or statistics just makes it obvious that you have two different sets on numbers. 1 doesn't mean the same thing in every instance in your programming and the functional programming side of me hates that.
- b_tterc_p 8y ago“Objectively preferred for me” sounds an awful lot like it’s subjective
- oblio 8y agoA ton more people do high level programming, than low level programming. You guys build the tools and many more people use them.
- simondanisch 8y agothat may be your impression, because you dont know julia's powerful, no overhead indexing abstractions yet ;) i also write lots of graphics low level code, and i couldn't be more glad that i don't need to do those error ridden indexing calculations anymore, since they're simply not needed... note, that you can also seamlessly create new array types that store 0 indices into other arrays - and because of julia's great composability, i can make them work with my indexing agnostic algorithms while being 0 overhead compatible with opengl's memory layout :)
- sammorrowdrums 8y agoIt's the difference between numbering the contents of the list (1 indexing), and measuring the distance from the beginning of the list to the start of the item (0 indexing). Personally I'm happy to switch between both, and they both have positives and negatives when I actually write code. 0 indexing is not incorrect, or incompatible with maths, it is just a different way of conceiving of lists/arrays by considering the index to more like the distance from the beginning. The first item begins 0 spaces from the start position. That is why in that context array length is usually the highest index + 1, because length is the distance from the start position to the end of the list, whereas the index is the start position of the item in the list. I will concede that 0 indexing is a little too close to the storage paradigm for arrays (i.e. a sequential list of items of n bytes) and that when so often these arrays point to more complex data-structures / objects, the distance doesn't make as much sense as the item number... but meh - I'd take Python generators / iterators at the expense of 0 indexing any day.
- coldtea 8y ago>It's the difference between numbering the contents of the list (1 indexing), and measuring the distance from the beginning of the list to the start of the item (0 indexing). The problem is that one is indeed an indexing (numbering the contents 1...X...N and asking for item X, customers[X]), whereas the other is not, but is used as an indexing (e.g. customers[5] is not getting the 5th item but the sixth).
- Twisol 8y agoWhere does your definition of "an indexing" originate? The word "index" literally means "to point at" (hence, index/pointer finger), and in this sense, every element may indeed be indexed -- in this case, by means of a unique integer. If I had to give a name to the concept you're talking about, it would be an "ordinal index".
- coldtea 8y ago>If I had to give a name to the concept you're talking about, it would be an "ordinal index". Which is both the naive understanding of a numeric index in everyday life in general, and the most common case in mathematics (and most math/scientific software).
- tombert 8y agoI had a job about 7 years ago doing Coldfusion and Flash. Coldfusion is 1 indexed and Actionscript is 0 indexed...this threw me off enough to the point of having a near-religious aversion towards explicit indexing, and while I've largely drunk the functional Kool-aid where I almost exclusively use maps and filters and reduce. I really do with the 1 indexing had stayed around, since I feel like it's more natural to say the 1st element, instead of the 0th.
- phkahler 8y ago>> I really do with the 1 indexing had stayed around, since I feel like it's more natural to say the 1st element, instead of the 0th. It's not the 0th element. It is the 1st element and has an offset of 0 from the beginning of the array. Not saying it's better or worse, but that if you change the words you use to describe it, you may find it easier to use. To my surprise, I just learned that ranges in Rust don't include the end number which felt incredibly stupid from a conceptual point of view (python too). But is syntactically useful when doing: for x in 0..len(my_array) { My preference would be that a range include the end number and the language provide more python-like iterators and list comprehensions. I am aware that there is a library that provides more python-like syntax, but that doesn't change the oddness of ranges in either language. I guess I just need to remember that the interval is open on one end. Which brings to mind the notion of using [0..n] or [0..n) in a language...
- coldtea 8y ago>It's not the 0th element. It is the 1st element and has an offset of 0 from the beginning of the array. It should be indexed with its position then a[1], as we do in all other aspects of life (and in math), and not with it's offset.
- umvi 8y ago> as we do in all other aspects of life You mean like elevators? You may be surprised to learn that elevators in America are 1-indexed (ground floor == floor 1), but in Europe they are 0-indexed (ground floor == floor 0).
- contravariant 8y agoFor what it's worth mathematics is more than flexible enough to handle both 0 and 1 based indexing. Using 1 based just looks neater since you can count x_1, ..., x_n rather than x_0, ..., x_{n-1}. Sometimes both are used at the same time e.g. if you add an extra coefficient at the start rather than at the end, this happens particularly when dealing with wedge products where the parity of the new index matters. Also it's usually a bad sign if you need to worry too much about what index you used, you might be better of using index sets with whatever structure you need (and only the structure you need). In program languages that support it generous application of ranges and generators tends to get rid of most complications.
- baldfat 8y agoThe issue is 1 will mean different things. That should be a bigger issue than anything else. When you are doing math 1 + 1 = 2 always means two. When you are getting the 1 column we are getting the second column. This while makes sense when doing certain lower level programming this makes no sense with functional or higher level programming.
- bobochan 8y agoVBA actually lets you decide at the top of each module whether to use 0 or 1 based indexing. The default value is 0, but you can specify "Option Base 1" to change that. There is an interesting note in the Wikipedia page for "Dartmouth BASIC" which says the second edition "also allowed arrays to begin as subscript 0 instead of 1. This was especially useful for representing polynomials."
- dmix 8y ago+ Elixir: Regex and Binary indexes are zero-based, List and Tuple are one-based
- yellowapple 8y agoAre they, though? The relevant functions in Enum all seem to be zero-based, for example: iex> [:foo, :bar, :baz] |> Enum.at(1) :bar Not that it really matters anyway. Like with Erlang, in the vast majority of cases where I'd normally reach for querying a list element by index, pattern matching is the better / more idiomatic option. Compare: foo = list |> Enum.at(0) bar = list |> Enum.at(1) baz = list |> Enum.at(2) rem = list |> Enum.slice(3..-1) with: [foo, bar, baz | rem] = list Both give you the exact same values of foo/bar/baz/rem, but the latter is arguably more readable and concise, and entirely avoids the 0 v. 1 debate.
- pjacotg 8y agoDijkstra makes an interesting argument for 0 based indexing in EWD831. https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...
- deleted 8y ago[deleted]
- goerz 8y agoIt's the only sensible choice for a numerical programming language
- roblabla 8y ago0-based indexing is closer to the memory representation, but 1-based indexing is closer to how we actually think about arrays. We say the first element, not the zeroth element. Nothing wrong with 1-based indexing except old habits die hard.
- throwaway287391 8y agoCall it bikeshedding but I totally agree. As someone who used to use Matlab (since it was what more or less everyone else in machine learning did at the time) and was immensely relieved to switch to NumPy a few years back, I’d love to give Julia a whirl but I just can’t stomach going back to a 1 indexed language. I’m surprised nobody maintains a 0 indexed fork of Julia yet (Juli0, anyone?).
- mcabbott 8y agoIf you want to take it for a spin, challenge yourself not to write anything which cares about this. It will force you to learn the some neat features (e.g. for N-dim arrays) instead of indexing with your bare hands like you're in C. And is good style anyway, to be generic to things like https://github.com/JuliaArrays/OffsetArrays.jl https://github.com/JuliaArrays/OffsetArrays.jl
- lenticular 8y agoMath uses base 1, and so does Fortran and Matlab. While Julia is an incredibly powerful language with things like user-defined unboxed structs and homoiconicity, a key design goal is to make it easy to learn for scientists and engineers who are not professional programmers. Since the vast majority use Matlab, the one-based indexing makes sense. One-based indexing works just as well as 0-based. I've done a lot in the past in Fortran 90 and (regrettably) Matlab. Some things are very slightly harder, some things are very slightly easier. At any rate, this isn't Fortran 77. You shouldn't be fiddling around with indices much. The bigger difference IMO is Julia uses Fortran-style column-major ordering, instead of row-major like C and Python. I actually
- wycy 8y agoFun fact: arrays in Fortran are also based on 1 by default, but they can be defined to start at 0, or even arbitrary negative numbers. The following are all valid: integer :: array1(5) integer :: array2(0:4) integer :: array3(5:10) integer :: array4(-4:4)
- dagw 8y agoJulia also supports this (called Offset Arrays)
- wycy 8y agoInteresting. Doesn't this solve the problem then for people who can't get into 1-indexed arrays?
- dagw 8y agoI suppose it kind of does for your own code, but you have to explicitly 'cast' all your arrays to 0-index arrays and it might break anything that assumes it's dealing with a normal 1-index array.
- dagw 8y agoAnd realistically in many cases you won't even notice the indexing as you'll either be iterating over the array or using an array operator rather than accessing elements via an index. And in the remaining cases, much of the time whether the index is 0-based or 1-based won't affect the way the final code looks. Still, it's nice to have the option to 0-index in the few cases where it does make your code cleaner.
- renox 8y agoThe problem is that it's not the default.
- wbl 8y agoPerl has a global variable that does the same thing.
- m_mueller 8y agoas someone who's written a lot of Fortran and Python for the same project I fail to see the problem. I find something like row- vs. column order differences harder to deal with. 1 vs. 0 based is just a matter of choice, a developer should be able to adapt, just like tabs vs. spaces etc.
- SiempreViernes 8y agoI think the exact amount of spaces that should make up a tab is an even more controversial point. I'd love to see what happens to the tabs vs spaces debate once someone makes tabs that aren't an integer multiple of spaces wide.
- taeric 8y agoTabstops are really old concept and were never really a set number of spaces wide. Used to, you had physical stops on the typewriter that a tab would advance to. So, that world was and is a long time ago. We just don't typically give a way for people to set tabstops in most environments, therefore it was chosen that tabs would advance a certain number of spaces.
- deleted 8y ago[deleted]
- synthmeat 8y agoCan't reply anymore to flagged-to-death sibling, but wrt "1-based array indexing": I've actually found behaviour of "zero-avoidance" a good battle-tested heuristics to coding. A lot of numeric spaces can be mapped as to be >0 or >0<. Obviously (?) not all of them can, but it's helpful in reducing cyclomatic complexity in logic code, as well as to consumers so they can uniformly handle all falsey values. Arithmetic is much safer without 0.
- mathdog 8y agocyclomatic complexity in logic
- vectorEQ 8y agooffset 1 is logical if you look at the machine code / data in memory. if you have array [a,b,c,d] array[0] is a which in computer is logical. why? because it stored in memory 'abcd' (forgetting endianness for sake of argument...) and the offset from the base pointer to a is 0. so it makes perfect sense for arrays to start at 0, as there is no offset from the base... there is not 1 item offset from the base :s if you find it confusing i would say learn how computers actually operate instead of arguing from some theoretical frame of mind which has nothing to do with how computers work. a computer isn't mathematics or some arithmetic machine. just because arithmetic is safer without 0 doesn't mean it's logical for a computer to suddenly have different array indexing. array indexing on a computer has nothing to do with maths. just memory layout and pointers... #addsfueltofire
- Tarq0n 8y agoOk, but why should that influence a managed language with no pointers?
- giornogiovanna 8y agoIt shouldn't. One-based indexing is what all the research uses, so it is undeniably the better choice for Julia. But zero-based indexing isn't just a memory trick, it makes lots of math easier when you're concatenating ranges or slicing arrays or doing modular arithmetic anywhere near an array.
- tzs 8y agoI once had occasional to implement several of the algorithms from the second part of Knuth volume 2, in C++. I don't recall the details, as this was a long time ago, but there were definitely times I was glad C++ used 0-based arrays, and there were definitely times when 1-based would have made for cleaner code. So I overloaded the () operator to make a(n), where a is an array, equivalent to a[n-1]. It looked a little odd at first if I mixed a[] and a() form in the same program, but it wasn't hard to get used to. I doubt I would recommend this in general, but it worked well for this particular application.
- dang 8y agoPlease don't post unsubstantive flamebait to HN. We don't need yet another low-quality spat about array indexing.