Statistics with Julia [pdf] • Hacker News Board

Re: Statistics with Julia [pdf]

#131

Post by goto11 » Mon, Jul 15, 2019, 6:58 AM UTC

kazinator wrote: post #130

goto11 wrote: post #128

Earlier quoted context omitted.

"Objectively speaking" there are pros and cons to each system. The largest pro of 0-based indexing is of course that it can correspond to a memory address plus an offset, which is the reason C (and derived languages) use 0-based. But it is also an objective fact that using 1-based indexing means that the index corresponds to the ordinal numbers, e.g. index 1 is the first element, index 2 is the second element and so…

Some machine-level implementation convenience is the smallest advantage. Zero based would be better even if it cost more at the machine level. Of course it doesn't cost more because the advantages are relevant at the implementation level also. > For example February is the 2. month, so if you have a list of the names of the months, you would expect month_names[2] to be February. That's not 1-based indexing being good…

But it is not some arbitrary historical accident that months are numbered from 1. It is the same reason the days of the month are numbered from 1. It is how ordinal numbers work!

Neil Armstrong was the 1st man on the moon - not the zero'th. Everywhere you have a sequence of discrete units, they are numbered starting from 1.

The thing with array indices in C is they are not ordinal numbers. They are offsets. Which means you can (at least in theory) do x[-1] to get the element before x. So a C array is not actually an array in the mathematical sense, it is just syntactic sugar for relative offsets in a larger array.

So what makes most sense? It really depends on what you want to achieve.

Re: Statistics with Julia [pdf]

#132

Post by kbd » Mon, Jul 15, 2019, 8:34 AM UTC

goto11 wrote: post #127

kbd wrote: post #77

Earlier quoted context omitted.

> The classic example is getting the last element of an array. Good point, in Python I don't notice that the last element is arr[len(arr)-1] because Python provides arr[-1]. I think in general your point is that it's natural for the nth element to be arr[n]. > The reason for zero indexing is historical, related to pointer offsets. There is that, but Dijkstra's paper makes the case from first-principles that the close…

> Dijkstra's paper makes the case from first-principles that the closed, open interval of [0,n) for sequences is the most appropriate He argues that it is the most appropriate when indexing into an array of the natural numbers starting with 0. If the array in question started with 1, one-based indexing would be most appropriate following exactly the same logic!

I don't think that's a correct reading. You're talking about this section, correct?

> When dealing with a sequence of length N, the elements of which we wish to distinguish by subscript, the next vexing question is what subscript value to assign to its starting element. Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i He never specifies the contents of the array, he's talking about subscripts (i.e. indexes).

Re: Statistics with Julia [pdf]

#133

Post by goto11 » Mon, Jul 15, 2019, 10:15 AM UTC

kbd wrote: post #132

goto11 wrote: post #127

Earlier quoted context omitted.

> Dijkstra's paper makes the case from first-principles that the closed, open interval of [0,n) for sequences is the most appropriate He argues that it is the most appropriate when indexing into an array of the natural numbers starting with 0. If the array in question started with 1, one-based indexing would be most appropriate following exactly the same logic!

I don't think that's a correct reading. You're talking about this section, correct? > When dealing with a sequence of length N, the elements of which we wish to distinguish by subscript, the next vexing question is what subscript value to assign to its starting element. Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i He never specifies the contents of the array, he's talkin…

You may be right, but in that case, why is the second range "nicer"? AFACT it is because he explicitly adds 1 in the first example but implicitly subtract 1 in the second, which makes it looks cleaner. If you want the N'th element of an array, the range in the first example is N ≤ i < N+1 while in the second it is N-1 ≤ i < N. Written out like that, I don't see how the second is obviously nicer.

Re: Statistics with Julia [pdf]

#134

Post by kbd » Tue, Jul 16, 2019, 3:55 AM UTC

goto11 wrote: post #133

kbd wrote: post #132

Earlier quoted context omitted.

I don't think that's a correct reading. You're talking about this section, correct? > When dealing with a sequence of length N, the elements of which we wish to distinguish by subscript, the next vexing question is what subscript value to assign to its starting element. Adhering to convention a) yields, when starting with subscript 1, the subscript range 1 ≤ i He never specifies the contents of the array, he's talkin…

You may be right, but in that case, why is the second range "nicer"? AFACT it is because he explicitly adds 1 in the first example but implicitly subtract 1 in the second, which makes it looks cleaner. If you want the N'th element of an array, the range in the first example is N ≤ i < N+1 while in the second it is N-1 ≤ i < N. Written out like that, I don't see how the second is obviously nicer.

Sure. Something is generally considered more elegant ("nicer") when it has fewer terms. (I'm really happy with my own argument above why Python's indexing is "optimal".) But I'd put what I think you're saying this way: Dijkstra asserts that '1 ≤ i I will say this though: in all the noise in this sub-thread, I never got any example in answer to my original question asking for any algorithm or formula that works out better with 1-based indexing (my original response was to its parent's claim that 1-based indexing results in fewer ±1s in practice). Except for maybe the "stride" examples[1] for which I still don't understand why the starting index is important. I say this not in victory (ha ha! zero-based indexes are clearly superior!) but in disappointment because I was hoping to gain understanding of why Julia/Matlab and others (which are more geared towards math/stats which is outside of my experience) made their indexing choice. Particularly because it's against the norm, they must have good reasons.

[1] https://news.ycombinator.com/item?id=20425500

Re: Statistics with Julia [pdf]

#135

Post by goto11 » Tue, Jul 16, 2019, 8:44 AM UTC

kbd wrote: post #134

goto11 wrote: post #133

Earlier quoted context omitted.

You may be right, but in that case, why is the second range "nicer"? AFACT it is because he explicitly adds 1 in the first example but implicitly subtract 1 in the second, which makes it looks cleaner. If you want the N'th element of an array, the range in the first example is N ≤ i < N+1 while in the second it is N-1 ≤ i < N. Written out like that, I don't see how the second is obviously nicer.

Sure. Something is generally considered more elegant ("nicer") when it has fewer terms. (I'm really happy with my own argument above why Python's indexing is "optimal".) But I'd put what I think you're saying this way: Dijkstra asserts that '1 ≤ i I will say this though: in all the noise in this sub-thread, I never got any example in answer to my original question asking for any algorithm or formula that works out be…

I'm actually arguing the opposite, that 0 ≤ i does have an extra term - it is just hidden! Where does the zero come from? The generalized form for picking the N'th number (with zero-based indexing) is N-1 ≤ i I'm not disputing the choice of closed-open rage, but I'm arguing the expressions are equally simple with either 1 and 0 based indexing.

As for an example where 1-based indexing is better, I had such an example in a another subthread: Translating between the numbers and names of months. Or indeed anywhere where you have a list of things and you want to pick them by ordinal numbers. E.g if you want the N'th president, it is simper to do presidents[N] than presidents[N-1].

Re: Statistics with Julia [pdf]

#136

Post by disgruntledphd2 » Tue, Jul 16, 2019, 12:06 PM UTC

eigenspace wrote: post #63

j88439h84 wrote: post #53

Earlier quoted context omitted.

What's the nuance? It's much faster?

The nuance is that for someone who mainly just calls functions from packages, they probably won’t notice any real speed difference since performance sensitive packages in python and R are typically written in C or C++. Additionally, there are various tools like Numba for accelerating Python code that will make certain restricted subsets of Python just as fast (or sometimes faster) than Julia. However, as soon as you…

I dunno about this. At work, we have an exhaustive model fitting procedure that takes a looooonnnng time.

I prototyped a quick julia implementation of a simple glm (almost identical code in Julia and R), and the julia code was approximately 10-20 times faster depending on the model.

This is definitely worth looking at (mind you, the costs of redevelopment of our code in Julia is probably prohibitive). That being said, this would encourage me to call out to julia from R for some of my more computationally heavy workloads.