Rename abstract numeric types like FloatingPoint and Complex?

[jiahao]

We've seen empirical evidence that new users sometimes use abstract numeric types like FloatingPoint or Complex in lieu of concrete types like Float64 and Complex128. The result is that users end up with slow code or even wrong code due to operations over variables with types like Array{Complex,2} or Vector{FloatingPoint}. (For example: this comment in #4796)

The unintentional use of abstract numeric types seems especially prevalent with FloatingPoint or Complex which share common prefixes with concrete types. Other abstract numeric types like Signed or Real do not seem prone to accidental misuse to the same extent.

Suggestions for new names? I'd propose something like FloatingPointAbstract or AbstractFloatingPoint to emphasize the abstract nature of the type. And perhaps something like ComplexCartesian instead of Complex to emphasize the canonical (real, imaginary) representation and to distinguish it from polar forms or other more esoteric representations.

[StefanKarpinski]

My votes:

• FloatingPoint ⟹ AbstractFloat
• leave Integer alone
• leave Complex alone
• introduce AbstractComplex as a supertype of Complex
• introduce PolarComplex as a polar representation of complex values

[tknopp]

Hard to get this consistent at this point. A radical change would be to use the Abstract prefix for all abstract types. Or use an I prefex like in C# (i.e. IArray, IComplex, IFloat).

[tknopp]

http://msdn.microsoft.com/en-us/library/8bc1fexb%28v=vs.71%29.aspx

[nalimilan]

@StefanKarpinski +1, but why not AbstractInt, for similarity with AbstractFloat? Integer is easily confused with Int.

[StefanKarpinski]

I hear you on the consistency issue. But something is off about AbtsractInt. Int is a specific implementation so AbstractInt is like writing AbstractInt64 or AbstractFloat64 – it's an oxymoron. In that case, it would have to be something more like AbstractInteger at which point, which may be ok, but why not just Integer then since there's no such concrete type.

[tknopp]

The more I think about it, the more I like the idea of introducing a common prefix for all abstract types. This makes it entirely obvious that one is dealing with an abstract type. The argument that a name is "free" like in the Integer case is not very strong in my opinion. It is a rather local name optimization for which one gives up clarity.

Since Abstract is a really long prefix I would formally propose the I convention (where I stands for Interface). In Gtk.jl prior to version 0.5 (I think) the I was used as a suffix by the way.

[johnmyleswhite]

I'm not a fan of the I prefix. It's pretty obscure.

Can I suggest a very different perspective here? I think the confusion we see on the mailing list is only correlated with names and tab-completion: the real cause is that many people coming to Julia have never worked with any type system before. So FloatingPoint confuses them because the idea of abstract types confuses them. And Complex confuses them because parametric types confuse them. We can maybe fix these specific issues with name changes, but there's a broader cultural problem: the manual doesn't provide any way for newcomers to learn what a type system is.

[quinnj]

-1 to I prefix as well.

I think it may also be prudent to consider other upcoming changes: #1470 will allow the use of Abstract types differently, #6975 talks about official Interfaces which will overlap, and #6984 is the covariance change. I think any name changes needed to be looked at in the broader scope of the future of the type system.

I'm also really looking forward to a lot of these changes; can't wait to throw them all together and get my "Julia-legs" again with the new system.

[JeffBezanson]

I kind of agree that it's not very satisfying to keep second-guessing which names will have an intended psychological effect. We thought FloatingPoint would be long and awkward enough that people would shy away from it. Maybe it's not a good name. But we should just pick good names and go with them.

The issue with Complex can't be solved by renaming. Types with parameters become abstract-ish when the parameters are left off, and this is a pretty subtle point to be sure. The same problem exists with Array, Vector, etc. For example creating an array of vectors with Vector[[1,2],[3,4]]. At one time I probably wanted to disallow using "incomplete" types as parameters (e.g. Array{Complex}). However in julia it turns out to be very difficult to disallow things. But it would be nice to do something about this.

[nalimilan]

The issue with Complex is... complex. ;-) But for Integer and FloatingPoint I think it's pretty simple: people get rightly confused because there's nothing in their names indicating they are abstract versions of Int(32|64)? and Float(32|64); the latter are abbreviations of the former, and it's not a big hint that they are abstract for newcomers.

@StefanKarpinski I'd be fine with AbstractInteger too.

[tknopp]

@quinnj: Absolutely, these things all need to be seen in a common scope. Still, explaining the difference between Int, Integer, Array, AbstractArray, FloatingPoint is quite difficult isn't it?

Let me ask the other way around: Would there be a drawback if we would introduce a convention how to name abstract types? On a related note, the bang-convention is IMHO great too.

[tknopp]

And it does not has to be the I prefix if everbody find this ugly. Abstract is also fine. The C# programmer in me makes the I prefix pretty natural.

[JeffBezanson]

I'm not opposed to a naming convention, especially if it's fairly lightweight (e.g. an A prefix) and we use it pretty consistently. Any might make a good prefix; Any is already the ultimate abstract type. AnyFloat, AnyInteger, etc. seem to convey the right idea.