Yes, let's return to the OP. Note that what the author *really wants* is to get the i-th potion of an array. Either integer division or 0-based alone can't solve this problem. a[i*100/n : (i+1)*100/n] needs both features.
As Eric puts it, user-written code can be as efficient as the built-in code. Tomas also provides another walk-around. However, if some body complains about this simple problem, he may not want to get his hand even dirtier. He is waiting for the develop team to give him an out-of-box solution. I have 2 solutions: 1) float slicing (not indexing) This enables `a[1:4.5] == a[1:4]` 2) iterable / array view ita = iter(a, n) ita[i] ita.next() On Mon, Apr 4, 2016 at 7:27 PM, Tomas Lycken wrote: > It’s also entirely possible to create a macro that lets / do what you > (the OP) want. > > @integer_division begin > > # in here, 5 / 2 == 2 > > end > > Basically, you’d just traverse the AST recursively and switch all calls to > / for calls to div. (I admit, though I wouldn’t want to do it myself, nor > would I want to maintain code that uses it, but at least the latter is > probably just a matter of taste…) > > The fact that this is even possible in Julia, is in my eyes a perfect > counter-argument to most of the pain points in the original post. I know of > no other language which is so painless to use when conforming to the > (usually very good) design decisions that have already been made, while > simultaneously giving the user the power to override almost anything if > desired. > > Similarly, it has already been brought-up that it’s quite possible to > create 0-indexed arrays (and making that even easier is even a current > hot-topic). > > As others have already brought up, there are lots of people who feel quite > opposite about both integer division and 0- or 1-based indexing. Satisfying > everyone isn’t going to be possible, but Julia comes damn close. > > // T > > On Monday, April 4, 2016 at 12:55:57 PM UTC+2, Tim Holy wrote: > > On Sunday, April 03, 2016 09:28:28 AM Scott Jones wrote: >> > With \\, would you worry about confusion from the fact that in a \\ b, >> a is >> > >> > > in >> > > the denominator? Especially if it gets called the "integer division >> > > operator." >> > >> > It might confuse some of the mathematicians, used to a \ b as a inverse >> > multiplication operator, however, other languages use a \ b for what in >> > Julia is div(a, b) or a÷b, >> > so I really don't think a definition of \\ as div(a, b) would be that >> much >> > of a problem, no worse than other things you have to remember in Julia, >> > and it's reminiscent of the // integer division operator in Python and >> Lua. >> >> Thinking about it a second time, there's another reason I'd recommend >> against >> this choice: if you're working with non-commutative numbers, for >> consistency >> \\ too should be reserved for forming Rationals rather than meaning >> something >> completely different. In other words, b//a means RightRational(b, a) >> (b*inv(a)) >> and a\\b means LeftRational(a, b) (inv(a)*b). I suspect our current >> Rational >> framework implicitly assumes commutativity, but that's a separate issue >> and >> one that, with a suitable number-traits system, is cleanly resolvable. >> >> I'm not trying to argue that making rationals with non-commutative >> numbers is >> a daily task, but to me consistency in the meaning of notation seems like >> the >> most important guiding principle. Code gets read many more times than it >> is >> written, so I don't mind a few extra keystrokes if it makes reading code >> clearer. >> >> But once again, it seems there just aren't enough characters on the >> keyboard. >> >> Best, >> --Tim >> >> >
