Add `Float16`

BigZaphod · December 11, 2019, 9:18pm

I personally find it rather hard to believe this would actually confuse anyone who is capable of working directly with Metal.

Syre · December 11, 2019, 9:29pm

I'd say many developers are "capable", but that's beside the point. The point is, if we are trying to avoid "doubt and confusion" by not making a typealias (which by the way, Xcode will happily tell you is a typealias if you were really unsure), in certain cases that could actually be more confusing to some people.

And, as I have said before, it's not a big deal if Half isn't included in this proposal, I'll just make the alias myself. But the idea that somehow a typealias is too confusing doesn't hold much water. If it did, why have typealiases at all?

Tino · December 11, 2019, 10:18pm

I guess there are even people who would happily discard this feature ;-) — but I personally have two major use cases:

A shortcut for a wordy type (especially function signatures)
When a type might be exchanged with an alternative

Often it's a combination of both reasons, but it's always in an restricted context. Actually, I couldn't name a single typealias in the stdlib...
Looking at other frameworks, there is CGFloat, but even that is its own type.
It would have some advantages if CoreGraphics had used a typealias, though, and I think it's fine to define Half in certain contexts — but I would not want two names for a single type in the stdlib.

Syre · December 11, 2019, 10:24pm

Here's an ironic one:
typealias Float32 = Float

Tino · December 11, 2019, 10:28pm

Imho that is an argument for typealias Float16 = Half...

Ben_Cohen · December 12, 2019, 6:06pm

CChar is one. And it causes all sorts of confusion because this:

let a = CChar("a")

...doesn't do what you might hope.

Alejandro · December 12, 2019, 6:31pm

Narrator:

// or UInt8 on some systems
let a = Int8("a") // Int8?.none or nil

Ilias_Karim · December 13, 2019, 3:31pm

I agree that to be consistent would be to typealias Float16 as Half. I also agree with Ben Cohen's response against nicknames.

Dante-Broggi · December 13, 2019, 5:01pm

Do note that that type alias has this comment on top of it:

github.com

apple/swift/blob/d3da328b8a8d4d5cceff39b5bb29b5c35efec446/stdlib/public/core/Policy.swift#L66-L75


      
          //===----------------------------------------------------------------------===//
          // Aliases for floating point types
          //===----------------------------------------------------------------------===//
          // FIXME: it should be the other way round, Float = Float32, Double = Float64,
          // but the type checker loses sugar currently, and ends up displaying 'FloatXX'
          // in diagnostics.
          /// A 32-bit floating point type.
          public typealias Float32 = Float
          /// A 64-bit floating point type.
          public typealias Float64 = Double

Tino · December 14, 2019, 4:52pm

That makes more sense to me as well - the names of our number-types all look rather archaic:
There's nothing wrong with int and float in isolation, but schemes like double and long don't scale well.
In the long run, I hope this will all be replaced with something like Int<Size> and Float<ExponentSize, FractionSize> (with some aliases for common types).

However, when the status quo is to have aliases like Float64 (which afaik is not nearly as common as double), it seems odd to ignore a popular* name like Half completely.

* according to other posts in this thread - I have no idea about actual prevalence in the wild

jpayoung · December 15, 2019, 1:15am

Where might one begin looking in the typechecker to see if this is still a bug?
I'm happy to try.

jpayoung · December 15, 2019, 1:17am

As a newbie here, it seems the intended * implementation of the current types is typealias Float = Float32 and typealias Double = Float64

If Float is corrected to Float32 (with the added typealias above), then the name Float16 would be consistent. A typealias to Half could be added if desired (see the discussion above), but that decision that is well above my pay grade / could be made later.

In either case, am I able to look into the typechecker issue? (i.e. might I be jumping in too deep?)
Thanks

* per the FIXME in the gist mentioned by @Dante-Broggi

dwaite · December 15, 2019, 6:10am

(bold added for emphasis for what I'm going on about in my unnecessary aside)

IIRC unfortunately it is not this easy to specify, as Float80 has a different fraction format with an explicit leading '1'.

Tino · December 15, 2019, 3:42pm

Don't worry - in my hypothetical future, default values for generic parameters are already well established ;-)

But to return to the near future:
I don't think there is any real resistance against adding a floating point type with 16 bits, and while there are strong preferences, afaics no one really insists on a certain name.
The thread is nearly a year old, and imho it's time to move to the next stage.

Syre · December 15, 2019, 3:49pm

Correct, as far as I’m concerned, it is really not a problem if the Half typealias is omitted. I think I’ve made decent arguments for it to be included, but it’s a very small thing and truly not that important to me.

wilshipley · December 17, 2019, 3:34am

Years ago when I first discovered I had to write all support for Float16s myself when talking to OpenGL shaders I was all

Then when I ported everything to Swift I was like oh boy I bet they support Float16 but then I was all

Then when I ported the OpenGL code to MetalSL I was all surely the Metal APIs support Float16 but then I was all

So this proposal is all

ASwiftUser · January 12, 2020, 6:33pm

The emojis really tell a story here.