rename: FloatingPoint => AbstractFloat

[StefanKarpinski]

No description provided.

[vtjnash]

what's the rationale for doing such a massive breaking change? it'll be quite a hassle to rename this in all packages (although i see that the deprecation is in place https://github.com/JuliaLang/julia/pull/12162/files#diff-7904f4ddd9158030529e0ed5ee8707eeR658)

[yuyichao]

Is this to emphasis that AbstractFloat is in fact "abstract"?

[jiahao]

Ref: #8142

[StefanKarpinski]

People are regularly confused by the name. Most recent example:

https://groups.google.com/forum/#!topic/julia-users/ih3xEucbcU8

I'm not 100% sold on this change, but I figured I might as well put it out there.

[tbreloff]

I think it makes sense, and not too hard for people to find/replace the name. If you're going down this road, you should also change Integer --> AbstractInt

[ScottPJones]

String already went to AbstractString, so this sounds OK to me, but maybe AbstractInteger instead of AbstractInt? (it isn't AbstractStr, for example)

[quinnj]

But the lower types aren't Integer64, so I'd be in favor of AbstractInt.

[dpsanders]

+1 for AbstractFloat and AbstractInteger

[JeffBezanson]

I really dislike AbstractInteger. It is way too verbose, and this type is quite useful.

[dpsanders]

True. AbstractInt, then.

[JeffBezanson]

No. Integer stays.

[jakebolewski]

Can we not do this rename then? It seems unnecessary.

[tbreloff]

Can we have a middle ground? What if AbstractInt and AbstractFloat are the actual types, and FloatingPoint, Integer, and AbstractInteger are type aliases? That could at least ease the pain of transition.

[jakebolewski]

Having multiple names for the same thing is always a bad idea. This is a pretty clear binary yes/no decision.

[JeffBezanson]

To me part of the issue is that Integer is a rather robust abstract concept, but "floating point" is not so much. Floating point is more of a concrete kind of number, but we don't have an exact definition of what it takes to be a FloatingPoint. Few languages (are there any others?) have such a type. So the name is less standard, and it might be worth calling extra attention to the fact that it's an abstract type. For example to many people "floating point" means Float32.

[tbreloff]

@jakebolewski We'll have to agree to disagree on that "always" statement. By that logic we should remove typealias as a keyword.

@JeffBezanson I understand your reasoning, but when I first started with julia it was not immediately obvious that Integer was abstract and Int was concrete. I was tripped up several times thinking I was effectively writing Int64 when I wrote Integer. I obviously got used to the concept, but it would have been very different if the types were Int vs AbstractInt

[jakebolewski]

I do agree that Integer is more of a robust concept. I feel the struggle here is not with concrete/abstract notions of Integer or FloatingPoint but that user's anchor on the name to represent a concrete notion of value type in other languages. In this sense Integer and FloatingPoint have the same problem.

[carnaval]

Am I mistaken that the reason for this is to avoid people mistakenly using abstract types as record fields ?

What about making a::A mean that A must be concrete so that a::Abstract is invalid (since the type would be empty). Then, you add, say, a ::< A which does what :: does now but stands out syntactically.

If you apply this to method arg tuples you can then distinguish between f{T}(::Vector{T},::T) which matches (Vector{Int},Int) but not (Vector{Integer},Int) whereas f{T}(::Vector{T},::<T) matches both. In a sense it could be a way to get the "some existentials are constrained to concrete types" rule explicit ?

(don't mind me, I might just need more coffee)

[malmaud]

It might be useful to have Lint.jl warn about non-concrete record types, if it doesn't already.

[andreasnoack]

Would it make sense to have something like an ApproximateNumber or NumberWithError (probably not the best names) instead of FloatingPoint. When deciding on whether the LU should pivot or not, I'm using T<:FloatingPoint but this is not the right choice for FixedPoints so having a common abstract type would help in that case.

[StefanKarpinski]

Maybe because I'm the one who made this PR but I've already found myself using AbstractFloat in place of FloatingPoint. I just this it's so much better. On the other hand, I'm not in favor of AbstractInteger. So basically, I favor merging this PR and leaving it at that.

[JeffBezanson]

Yes, I'm fine with this.

@andreasnoack I agree we should have a type like this, to sit above AbstractFloat and FixedPoint. Maybe RoundedReal?

[andreasnoack]

No big deal, but I'm wondering if you'd need the AbstractFloat if you had RoundedReal. I'd expect that it is mainly rounded property more than the floating point property that is important for dispatch.

[timholy]

+1 for AbstractFloat from me.

a type like this, to sit above AbstractFloat and FixedPoint

As another possible name, in Color.jl we currently use the term Fractional.

[JeffBezanson]

That's a good name but it sounds like it would also apply to Rational. I suspect the key property to dispatch on is whether results of operations will be rounded.

[ScottPJones]

👍 to AbstractFloat, it follows the pattern already established of AbstractString, AbstractVector, AbstractArray, AbstractRNG (why wasn't that AbstractRange?) etc.
Patterns like that make it easier for normal humans to remember.
Fractional seems misleading to me, because you can also use floating point types just to represent integers, including very big integers that don't fit in 64-bits.
Somewhat OT: it would be nice if the ? help system showed if a type were abstract or not, it shows if a type has subtypes, which implies that it is abstract, but if the abstract type has no subtypes, you can't tell.
That might reduce the potential confusion with abstract type names such as Integer and Unsigned that people don't want to expand to AbstractInteger etc.

[quinnj]

AbstractRNG => Abstract Random Number Generator

[ScottPJones]

Oh! That explains it. Thanks! (TLAs can be rather confusing at times, when you come from another domain)

[JeffBezanson]

the ? help system showed if a type were abstract or not

+1 that would be really good.

[StefanKarpinski]

Showing the type definition would be helpful (maybe without inner constructors) – this could quite easily be gotten via reflection.

[davidagold]

@StefanKarpinski Is there a way to access directly the actual type definition of Foo using reflection, or would one have to reconstruct it from, say Foo.super, Foo.parameters, Foo.mutable, Foo.abstract, fieldnames(Foo), etc?

[yuyichao]

@davidagold I guess you can just do what xdump does.

[davidagold]

@yuyichao Ahah! I've found myself looking for something like that a number of times. Thank you!

[JeffBezanson]

Rebased.

[tkelman]

There are changes to 3 binary files in contrib that probably shouldn't be here.

[StefanKarpinski]

Good catch, @tkelman.

[nalimilan]

+1 from me too. Better do this sooner than later.

[ivarne]

One of the things that appealed to me when learning Julia, was the cute names for the abstract types. Unfortunately they cause trouble for beginners, and the performance characteristics of Julia makes it rather important to know if a type is abstract.

I don't like this PR, because it doesn't actually make Julia easier to learn, but just pushes the issue on to Integer and Range. We should either go all in on abstract Abstract***, and add the prefix to the style guide for naming abstract types, or continue the original plan with cute names. Renaming one type at the time (when a julia-users is confused) is just annoying.

[StefanKarpinski]

There seems to be an unrelated issue with Travis tests running on legacy hardware.

[JeffBezanson]

I dispute the theory that names are either "cute" or "consistent".

[ivarne]

I didn't say cute isn't consistent. I said abstract Abstract*** isn't cute, and transitioning to non-cute names, but keeping a few cute ones, isn't consistent.

[tkelman]

We really need to fix #11200 before removing these in 0.5. Deprecation without warnings pretty much defeats the purpose.

[tkelman]

There seems to be an unrelated issue with Travis tests running on legacy hardware.

The issue on OSX looked like an unrelated timeout, on 64 bit Linux was a pollfd failure (we've probably got a bug lingering). The message about "legacy infrastructure" is going to be there for as long as we need to use sudo on Travis. They're trying to move people to use the Docker-based workers, which can't use sudo, you can only apt-get install packages from a whitelist which the juliadeps PPA isn't on. We could instead try doing it the way we do on appveyor and download a Julia nightly and use the big deps from there (they don't have separate libraries or headers for LLVM though), but that's a fair amount of work that no one has done yet. The Docker workers do have less of a queue time and let you cache things which could be useful, so maybe it's worth figuring out eventually. For now, ignore that message.