9

In Go, there's the type int which may be equivalent to int32 or int64 depending on the system architecture. I can declare an integer variable without worrying about its size with:

var x int

Why isn't there the type float, which would be equivalent to float32 or float64 depending on my system's architecture? I wish I could also do:

var x float
cd1
  • 15,908
  • 12
  • 46
  • 47

2 Answers2

13

float were removed in the release 2011/01/20.

You can still use a short variable declaration:

x := 0.

But as mentioned in the GO FAQ:

For reasons of portability, we decided to make things clear and straightforward at the cost of some explicit conversions in the code.

You can see the debate before 2011 in this thread:

I'm a little dismayed even to see the suggestion of getting rid of the unsized float and complex types.
People haven't had to really deal with this problem for a generation (a human generation, not a computer generation; the > early 90s was the last time this was really an issue), but this is exactly the moment in time when I think it's becoming relevant again.
Between the transition to 64-bit chips and the transition to non-Intel based platforms (mobile chips, GPUs, etc), I think it's a huge mistake to take out these types.

The problem with the analogy between integer types and float types is that:

  • in the case of integer types you don't care about the size unless it overflows.
  • In the case of float types, you always need to care about the size, because it always affects your answer (unless you're only doing arithmetic involving small integers * 2^n, in which case it's exact, in which case you'd be better off with a fixed-point representation).
    So there isn't the same possibility of "I just want a good representation".

There has never been a speed advantage to 32-bit floats except in terms of memory use (and cache), so the existing 32-bit float type isn't defined as a "fast" float. It's just there (I presume) because that's what it's called in C. I wouldn't object to that if the float64 were called "double", which it is in most languages I know.

But I really think the language would be nicer without the "float" type.
Size really does matter for any floating-point use, either because of memory consumption or because of required precision.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Though I believe float was ALWAYS 64-bit, regardless of architecture (not sure about complex). – Linear Jun 22 '14 at 18:45
  • @Jsor yes, 32bits float can lead to... troubles: http://stackoverflow.com/q/22337418/6309 – VonC Jun 22 '14 at 18:47
  • true, but it's necessary to have sometimes. Graphics hardware is so not optimized for 64-bit floats it's not even funny. They weren't even supported until a few short years ago. Edit: Of course, you're right that the issues with 32-bit floats points to why 64-bit should be the default. – Linear Jun 22 '14 at 18:50
  • I didn't know there were the types "float" and "complex" before! :-) – cd1 Jun 22 '14 at 18:56
  • @Jsor: Re: "I believe float was ALWAYS 64-bit": Well, that's not what the spec said; see https://code.google.com/p/go/source/browse/doc/go_spec.html?name=weekly.2011-01-19. – ruakh Jun 22 '14 at 18:57
8

With integers, it is very common to want an integer type whose size is the platform's native word size: this has performance benefits, as well as benefits for low-level interoperability with other parts of the system that use the word size.

With floating-point values, this is not the case. Even on 32-bit systems, double-precision floating-point (Go's float64) is generally much more common, and generally not slower, than single-precision (float32). Single-precision floating-point arithmetic is relatively uncommon, and is generally only useful when memory usage or input-output speed is a much stronger consideration.

So although you write that float "would be equivalent to float32 or float64 depending on [your] system's architecture", I'm not sure on what architecture you feel it should be equivalent to float32.

ruakh
  • 175,680
  • 26
  • 273
  • 307
  • before you explained this here, I'd say that on 32 bit systems, "float" should be equivalent to "float32". I didn't know that float64 is generally faster than float32 even on 32 bit systems. – cd1 Jun 22 '14 at 18:58
  • @cd1: I'm glad I explained that, then. That said, I should mention that there are systems where `float32` is faster (e.g., cases where there's no hardware support and floating-point arithmetic is therefore implemented entirely in software). So that's totally valid when it *is* the case; it's just that it generally *isn't*. – ruakh Jun 22 '14 at 19:03
  • So it seems that you are arguing that float64 is "better" in most cases. So fine, then "float" could just mean "float64". That way the programmer doesn't have to know the fine points of system architecture that you explained above. (There must be other good reasons why they dropped "float" from the language.) – Duncan Sep 20 '19 at 06:09