Python 3 changed the meaning of 1/2 to be 0.5, so arguing from a Pythonic perspective would seem to indicate that Julia has avoided Python's original mistake for / and chosen a behavior that Guido van Rossum and the the Python community at large consider to be sufficiently much better to warrant a rather long and annoying deprecation process. Also note that C and Python are inconsistent in what / means: in C it does truncated division while in Python it does floored division. Neither choice is obviously entirely better, which is itself a problem: so you want / to be integer division? Which one?
On Sat, Apr 2, 2016 at 4:18 PM, Matt Bauman <[email protected]> wrote: > I don't want to get too deep into the weeds here, but I want to point out > some things I like about Julia's closed ranges: > > * Julia's ranges are just vectors of indices. In exchange for giving up > Python's offset style slicing, you get a fully-functional mathematical > vector that supports all sorts of arithmetic. Idioms like `(-1:1)+i` allow > you to very easily slide a 3-element window along your array. > > * Since they represent a collection of indices instead of elements between > two fenceposts, Julia's ranges will throw bounds errors if the endpoints go > beyond the end of the array. I find these sorts of errors extremely > valuable — if I'm indexing with a N-element range I want N elements back. > > * The only thing that's special about indexing by ranges is that they > compute their elements on-the-fly and very efficiently. You can create > your own range-like array type very easily, and it can even generalize to > multiple dimensions quite nicely. > > * Being vectors themselves, you can index into range objects. In fact, > they will smartly re-compute new ranges upon indexing (if they can). > > * In exchange for Python's negative indexing, you get the `end` keyword. > It can be used directly in all sorts of computations. In fact, you could > use it in your example, replacing the hard-coded 100 with `end`. Now it > supports arrays of all lengths. Circular buffers can be expressed as > `buf[mod1(i, > end)]`. > > Of course there are trade-offs to either approach, and it takes time to > adjust when moving from one system to the other. > > If you work a lot with images and other higher-dimensional arrays, I > recommend taking a look at Julia's multidimensional algorithms. I think > Julia has a lot to offer in this domain and is quite unique in its > multidimensional support. http://julialang.org/blog/2016/02/iteration > > > On Saturday, April 2, 2016 at 7:55:55 AM UTC-4, Spiritus Pap wrote: >> >> Hi there, >> >> TL;DR: A lot of people that could use julia (researchers currently using >> python) won't. I give an example of how it makes my life hard, and I try to >> suggest solutions. >> >> Iv'e been introduced to julia about a month ago. >> I'm an algorithmic researcher, I write mostly research code: statistics, >> image processing, algorithms, etc. >> I use mostly python with numpy for my stuff, and C/++ when I need >> performance. >> I was really happy when I heard of julia, because it takes the simplicity >> of python and combines it with JIT compilation for speed! >> >> I REALLY tried to use julia, I really did. I tried to convince my friends >> at work to use it too. >> However, there are a few things that make it unusable the way it is. >> >> Decisions that in my opinion were made by people who do not write >> research-code: >> 1. Indexing in Julia. being 1 based and inclusive, instead of 0 based and >> not including the end (like in c/python/lots of other stuff) >> 2. No simple integer-division operator. >> >> A simple example why it makes my *life hard*: Assume there is an array >> of size 100, and i want to take the i_th portion of it out of n. This is a >> common scenario for research-code, at least for me and my friends. >> In python: >> a[i*100/n:(i+1)*100/n] >> In julia: >> a[1+div(i*100,n):div((i+1)*100,n)] >> >> A lot more cumbersome in julia, and it is annoying and unattractive. This >> is just a simple example. >> >> *Possible solutions:* >> The reason I'm writing this post is because I want to use julia, and I >> want to to become great. >> *About the division:* I would suggest *adding *an integer division >> *operator*, such as *//*. Would help a lot. Yes, I think it should be by >> default, so that newcomers would need the least amount of effort to use >> julia comfortably. >> >> *About the indexing:* I realize that this is a decision made a long time >> ago, and everything is built this way. Yes, it is like matlab, and no, it >> is not a good thing. >> I am a mathematician, and I almost always index my sequences expressions >> in 0, it usually just makes more sense. >> The problem is both in array (e.g. a[0]) and in slice (e.g. 0:10). >> An array could be solved perhaps by a *custom *0 based *array object*. >> But the slice? Maybe adding a 0 based *slice operator*(such as .. or _)? >> is it possible to do so in a library? >> >> I'd be happy to write these myself, but I believe these need to be in the >> standard library. Again, so that newcomers would need the least amount of >> effort to use julia comfortably. >> If you have better suggestions, I'd be happy to hear. >> >> Thank you for your time >> >
