Since supertype(Number) == Any, the most abstract number-like entity that
Julia has to offer with the current hierarchy is Number. Most packages I
have seen that implement number-like types which are outside of the Reals
use Number as their supertype. This is more helpful, generally, than
having Quaternions, Dual Numbers etc be direct subtypes of Any.
On Monday, April 4, 2016 at 7:06:17 AM UTC-4, Sheehan Olver wrote:
>
>
> Rational is currently restricted to numbers: Rational{T<:Number}.
> I’m assuming Number implicitly means commutative number (i.e., not
> Quaternion).
>
>
>
> > On 4 Apr 2016, at 8:55 PM, Tim Holy <[email protected] <javascript:>>
> 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
> >
>
>
