It may have been already proposed sometimes, for some other things (and
possibly by myself), but, what about a module that simple defines
*macro ~(x,y); div(x,y); end*
? Enabling code like *4~3*.
Would it be considered idiomatic enough to use such available option?
On Tue, Apr 5, 2016 at 9:19 PM Scott Jones <scott.paul.jo...@gmail.com>
wrote:
>
>
> On Tuesday, April 5, 2016 at 2:42:56 AM UTC-4, Tomas Lycken wrote:
>>
>> There are only 6 uses of // outside of rationals.jl in base (4 of those
>> are in mpfr.jl), compared to 187 uses of div, and 22 uses of ÷. (that’s
>> uses, not definitions, exports, documentation, although the ratios are very
>> similar).
>> Looking at packages, it seems also that div is used frequently, and many
>> times more than // for rational numbers.
>>
>> I don’t think counting usages of // vs ÷ is necessarily fair, since I
>> think // is used less than it should be (for reasons I eventually
>> expanded into a section in the Julia style guide
>> <http://docs.julialang.org/en/release-0.4/manual/style-guide/#avoid-using-floats-for-numeric-literals-in-generic-code-when-possible>).
>> More fair would be to compare the number of usages of ÷ with the number
>> of usages of // *plus the number of float literals*. (The results might
>> be the same, though - I haven’t actually made the comparison).
>>
> I have nothing against using Rationals, and I agree, they should be used
> instead of fp literals (because those are always binary and usually inexact
> in Julia) in many cases, but that wasn't my point. In retrospect (but
> nothing to be done now), I think it might have been better to use // for
> integer division, and maybe /// for Rationals, for two reasons, integer
> division is probably still going to be used more frequently than Rationals
> (if Rationals were needed so frequently, why don't any of the other
> languages have support for them, but all that I've used have an integer
> division operator), and secondly, to minimize confusion, as Python, Lua
> (and I believe some others) use // for integer division.
>
>
>> But more to the point:
>>
>> That is your opinion, however a number of other people disagree.
>>
>> *Exactly.* People disagree on this, and there seems to be a shortage of
>> ASCII characters (or character sequences) for everyone to have it all. In
>> the table you posted a while ago, I notice that Julia is the *only*
>> language which has infix operators for both (int, int) -> float, (int,
>> int) -> int and (int, int) -> rational division. I’m not saying the
>> design of this is final (software design is never final for software
>> reasons - only for people reasons…) but to me it looks like Julia has
>> already hit a sweet spot in supporting as much as possible for as many
>> tastes as possible.
>>
> That chart shows that Julia is the *only* language that does not have a
> one or two *ASCII* character infix operator for integer division.
> I imagine that it is probably one of the most used operators that doesn't
> have an ASCII sequence in Julia.
> Unicode operators are a major pain to deal with, especially when you have
> to type them differently in Jabber, Google+, GitHub, Emacs, Atom, the Julia
> REPL, etc. Solutions such as "just customize your editor" don't work well
> also when you are dealing with a number of developers, all working together
> in a team using julia. That just multiplies the pain.
>
> There are also problems with the way the conversions are handled, when you
> have Integer / Integer, in that data gets lost silently,
> and no matter what the type of the integers happens to be, you end up with
> Float64.
> After reading the part you added to the Style Guide, I now think that the
> best way of dealing with Integer / Integer in Julia would be
> to return the same as //. That would give an *exact* answer always, which
> could be later converted to whatever size float desired
> (or to an integer, without losing information silently).
>
> Here's some examples, which shows how Integer / Integer -> Float64 can
> introduce bugs silently, and why changing it to
> /(x::Integer, y::Integer) = x//y
> instead of the current:
> /(x::Integer, y::Integer) = float(x)/float(y)
> would be a very nice choice:
>
> *julia> **1234567890123456789/2*
>
> *6.172839450617284e17*
>
> *julia> **1234567890123456789÷2*
>
> *617283945061728394*
>
> *julia> **Int64(1234567890123456789/2)*
>
> *617283945061728384*
>
> *julia> **Int64(1234567890123456789//2)*
>
> *ERROR: InexactError()*
>
> * [inlined code] from ./rational.jl:76*
>
> * in Int64(::Rational{Int64}) at ./sysimg.jl:48*
>
> * in eval(::Module, ::Any) at ./boot.jl:237*
>
>
> *julia> **Int64(1234567890123456789/3)*
>
> *411522630041152256*
>
> *julia> **Int64(1234567890123456789÷3)*
>
> *411522630041152263*
>
> *julia> **Int64(1234567890123456789//3)*
>
> *411522630041152263*
>
> As you can see, the silent conversion to Float ends up giving incorrect
> answers.
>
>> Note that what the author *really wants* is to get the i-th potion of an
>> array
>>
>> Tamas Papp already posted an idiomatic solution for this:
>>
>> Define
>>
>> portion(i,n,m=100) = 1+div(i*m,n):div((i+1)*m,n)
>>
>> and use
>>
>> a[portion(i,n)]
>>
>> // T
>>
> That would only help that one particular case, not the myriad other cases
> where div or \div<tab> are being used in Julia code already,
> both in Base and many many packages (I've grepped through all of the
> packages in METADATA.jl - it's quite a lot).
>
> That's why I'd still like to see *some* easy to type two character ASCII
> sequence for integer division (and I think others would also
> prefer that to using \div<tab> (or whatever you have to do in your editor)
> or div(a, b) all the time).
>
> - Scott
>
> On Tuesday, April 5, 2016 at 4:55:05 AM UTC+2, Scott Jones wrote:
>>
>>
>>>
>>> On Monday, April 4, 2016 at 7:27:40 AM UTC-4, Stefan Karpinski wrote:
>>>>
>>>> Number does not imply or assume commutativity. The Quaternions package
>>>> provides a Quaternion type which is a subtype of Number. Rational, however,
>>>> only allows integer numerators and denominators. Since integer
>>>> multiplication is commutative, rational multiplication is too. But I still
>>>> think it best to reserve \\ with an analogous meaning to //. There are
>>>> already two syntaxes for integer division, which is plenty.
>>>>
>>>
>>> That is your opinion, however a number of other people disagree. Every
>>> other language I've dealt with has had a simple ASCII sequence for integer
>>> division, / (in C, C++, Java, Python2 with integer operands), \ (in Mumps &
>>> Caché Object Script), or // (Python and Lua).
>>> (and no, typing \div<tab> in the REPL and something else in an editor
>>> [as well as having to customize one's editor] just to get a Unicode ÷
>>> character, is not really that useful)
>>>
>>> About \\ in particular, that's fine then, probably better to reserve
>>> that for rationals.
>>> To me, it does seem a bit strange though that // was picked for
>>> rationals in Julia, something sure to cause confusion for people coming
>>> from Python (which seems to be a large part of people moving to Julia) or
>>> Lua, when integer division is used so much more frequently than rational
>>> numbers.
>>> There are only 6 uses of // outside of rationals.jl in base (4 of those
>>> are in mpfr.jl), compared to 187 uses of div, and 22 uses of ÷. (that's
>>> uses, not definitions, exports, documentation, although the ratios are very
>>> similar).
>>> Looking at packages, it seems also that div is used frequently, and many
>>> times more than // for rational numbers.
>>>
>>> What about a different two character ASCII sequence that is currently a
>>> syntax error?
>>> I think /| could be used, and could be easily remembered as being
>>> integer division (unlike ÷), it could be described as doing a division /
>>> and cutting off the remainder |.
>>>
>>
>>
>
