<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 23, 2016 at 9:40 PM, David Sweeris <span dir="ltr"><<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On May 23, 2016, at 8:18 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> Int is the same size as Int64 on a 64-bit machine but the same size as Int32 on a 32-bit machine. By contrast, modern 32-bit architectures have FPUs that handle 64-bit and even 80-bit floating point types. Therefore, it does not make sense for Float to be Float32 on a 32-bit machine, as would be the case in one interpretation of what it means to mirror naming "conventions." However, if you interpret the convention to mean that Float should be the largest floating point type supported by the FPU, Float should actually be a typealias for Float80 even on some 32-bit machines. In neither interpretation does it mean that Float should simply be a typealias for what's now called Double.<br>
</span>IIRC, `Int` is typealiased to the target's biggest native/efficient/practical integer type, regardless of its bit-depth (although I believe some do exist, I can’t think of any CPUs in which those are different). I don’t see why it shouldn’t be the same way with floats… IMHO, `Float` should be typealiased to the biggest native/efficient/practical floating point type, which I think is pretty universally Float64. I’m under the impression that Intel’s 80-bit format is intended to be an interim representation which is automatically converted to/from 64-bit, and loading & storing a full 80-bits is a non-trivial matter. I’m not even sure if the standard “math.h" functions are defined for Float80 arguments. If Float80 is just as native/efficient/practical as Float64, I wouldn’t object to Float being typealiased to Float80 on such platforms.<br>
<span class=""><br>
> Another issue to consider: a number like 42 is stored exactly regardless of whether you're using an Int32 or an Int64. However, a number like 1.1 is not stored exactly as a binary floating point type, and it's approximated *differently* as a Float than as a Double. Thus, it can be essential to consider what kind of floating point type you're using in scenarios even when the number is small, whereas the same is not true for integer types.<br>
</span>Oh I know. I’m not arguing that floating point math isn’t messy, just that since we can use “Int” for when we don’t care and “IntXX” for when we do, we should also be able to use “Float” when we don’t care and “FloatXX” when we do. If someone’s worried about the exact value of “1.1”, they should be specifying the bit-depth anyway. Otherwise, give them most precise type which can work with the language’s goals.<br></blockquote><div><br></div><div>I wouldn't be opposed to renaming Float and Double to Float32 and Float64, but I would care if Float were typealiased to different types on different platforms. That solution is a non-starter for me because something as simple as (1.1 + 1.1) would evaluate to a different result depending on the machine. That's a problem. An analogous issue does not come into play with Int because 1 + 1 == 2 regardless of the size of Int. Swift traps when the max value that can be stored in an Int is exceeded, so it is not possible to obtain two different results on two different machines.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have we (meaning the list in general, not you & me in particular) had this conversation before? This feels familiar...<br></blockquote><div><br></div><div>It does, doesn't it? I've been reading this list for too long.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Dave Sweeris</blockquote></div><br></div></div>