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
>
>
