Numerical types and machine word size

[Júlio Hoffimann]

Dear all,

By reading the docs, Int is an alias for either Int32 or Int64 depending on the WORD_SIZE of the machine where Julia is running.

Why we do not have a similar Float construct for floating points? Can we say Real is either Float32 or Float64 likewise? Is there any theoretical difference?

Best,

Júlio.

[Jacob Quinn]

See answers to the same question here: https://groups.google.com/forum/#!searchin/julia-users/Float$20Float32$20Float$2064/julia-users/1tDvMbfCUEE/BJCu0-S7OawJ

[Stefan Karpinski]

Integer size is system-dependent while floating-point size is not. The 8087 already had 64-bit floats and every x86 since the i486 has too, so there's no reason to change the size of floating-point numbers on different systems. When you write 1.0 in Julia, it is always a Float64.

Real is an abstract type that has many non-floating-point subtypes, including all integer types and rationals. Being a subtype of Real means, as the name suggests, that a type represents values on the real number line. There is a FloatingPoint abstract type, which is closer to what you're thinking of, but it also includes BigFloat.

On Tue, Jul 29, 2014 at 11:19 AM, Júlio Hoffimann <julio.h...@gmail.com> wrote:

[Júlio Hoffimann]

2014-07-29 13:10 GMT-03:00 Stefan Karpinski <ste...@karpinski.org>:

Integer size is system-dependent while floating-point size is not. The 8087 already had 64-bit floats and every x86 since the i486 has too, so there's no reason to change the size of floating-point numbers on different systems. When you write 1.0 in Julia, it is always a Float64.

Nice.

 

Real is an abstract type that has many non-floating-point subtypes, including all integer types and rationals. Being a subtype of Real means, as the name suggests, that a type represents values on the real number line. There is a FloatingPoint abstract type, which is closer to what you're thinking of, but it also includes BigFloat.

That is what I thought. But since Float64 is ubiquitous, why not the cleaner alias Float instead? It would improve readability by a little yet considerable amount, IMHO. The "64" in the symbol is boiler plate for most use cases.

Júlio.

P.S.: Why Julia users do not hang on IRC? Such trivial questions would be addressed instantly. I guess this mailing list is being misused as an IRC channel. (~54 emails per day).

[Stefan Karpinski]

On Tue, Jul 29, 2014 at 5:19 PM, Júlio Hoffimann <julio.h...@gmail.com> wrote:

P.S.: Why Julia users do not hang on IRC? Such trivial questions would be addressed instantly. I guess this mailing list is being misused as an IRC channel. (~54 emails per day).

Some do. Personally, I find IRC to be far too much of a continual distraction. Email I can answer when I want to. With IRC, there's also no record of the discussion, which would just mean having to answer the same questions more often. IRC might be quicker and more convenient for the people asking questions, but not for the people answering them.

[Júlio Hoffimann]

Some do. Personally, I find IRC to be far too much of a continual distraction. Email I can answer when I want to. With IRC, there's also no record of the discussion, which would just mean having to answer the same questions more often. IRC might be quicker and more convenient for the people asking questions, but not for the people answering them.

I totally agree. On the other hand, having your inbox full of discussion is annoying. No one is forced to answer questions on IRC instantly, and I usually answer them during procrastination. If all users here come join us on IRC, it would be really great.

Regarding the Float typealias, what do you think?

Júlio.

[Stefan Karpinski]

What would Float be an alias for?

[Júlio Hoffimann]

I'm following the analogy for Int:

if is(Int,Int64)

  typealias Float Float64

else

  typealias Float Float32

end

User code would be cleaner:

function foo(a::Float, b::Float)

end

vs.

function bar(a::Float64, b::Float64)

end

Júlio.

[Júlio Hoffimann]

This makes sense? Please correct me if I'm saying nonsense.

Júlio.

[Stefan Karpinski]

Float would always be Float64.

[John Myles White]

I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability.

-- John

[Júlio Hoffimann]

2014-07-29 19:32 GMT-03:00 John Myles White <johnmyl...@gmail.com>:

I think the confusion is that Julio assumes Int is used for brevity, when it is actually used for cross-platform compability.

 -- John

Yes, I assumed the Int alias had these two goals: brevity + portability. I still think a cleaner Float alias would be useful to avoid typing 64 everywhere.

Júlio.

[John Myles White]

One of the things I like about the Julia community is a broad preference for clarity over brevity. Think of it as the opposite of the Perl culture.

In this case, Float would be less, rather than more, clear because our Float would describe a type that most languages would call Double.

 -- John

[Júlio Hoffimann]

2014-07-29 19:50 GMT-03:00 John Myles White <johnmyl...@gmail.com>:

In this case, Float would be less, rather than more, clear because our Float would describe a type that most languages would call Double.

In my humble opinion we can call it Float without confusion and forget about other languages naming conventions (i.e. double). This is up to you, but to me Float is quite clear, it's the "default" floating point type. And except for graphics stuff (my limited view of science), no one needs such distinction between Float32 and Float64.

Júlio.

[Stefan Karpinski]

Yes, Float is a bad name for Float64 since anyone coming from C or Fortran would expect Float = Float32 and Double = Float64.

If you're writing Float64 a lot I think you may be over constraining your type signatures. Most algorithms that make sense for Float64 also make sense for Float32 and BigFloat and possibly also for integers and rationals, maybe all real number representations. Unless you very specifically need a 64-bit float for your code to work, why restrict it more than necessary? And if you really need a 64-bit float – not a 32-bit one or a 256-bit one – then it seems quite fitting to have "64" in the type signature.

[Stefan Karpinski]

Ignoring other languages people are likely to be used to is not really the Julian way. People come from various language backgrounds and we'd like to make using Julia as comfortable for as many people as possible, if the cost is not too great. It's quite likely that many people will be working in both Julia and C quite a bit (I do this a lot). Inverting the meanings of a basic C type is just confusing. 

[Júlio Hoffimann]

If only Float exists in Julia, then there is no door for confusion with Double. A user coming from a C background will soon notice that Float is the type he is looking for. Furthermore, a simple short note on the manual is enough to make it even clearer.

Júlio.

[John Myles White]

I think you're assuming people's beliefs about programming languages are simpler to modify than they've proven to be in our experience.

Here's an experiment you could try to see if I'm right: over the course of six months, reply to every e-mail you see on julia-users that derives from a misunderstanding of the manual.

My hypothesis is that you'll find very early on in your experiment that short notes in the manual are almost never sufficient to prevent confusion. For example, there are many different notes in the manual about why you shouldn't do any programming in the global scope, but we get e-mails about performance in the global scope at least once a week from users that haven't understood that section of the manual.

I contend that the name Float would have a similar effect.

-- John

[Jameson Nash]

Except that we already have Int != int, which becomes unfortunate when first trying to write code for c-interop. (I don't see adding a Float alias as particularly helpful -- and we do have Cfloat, if someone feels the need to be pedantic/consistent in their ccall and type structs.)

[Kevin Squire]

While 3D graphics packages are still in early development for Julia, I believe that community uses 32 bit floats almost exclusively, probably because of bandwidth constraints to the GPU (but someone with more knowledge should correct me). 

Cheers, Kevin

[Tony Kelman]

There were also architectural problems related to SIMD width (I think) on most GPU designs until fairly recently, causing operations on 64-bit doubles to be significantly more than 2x slower than 32-bit singles. This is not so much the case any more, but old habits die hard and if single precision is good enough, then you still do get a factor of roughly 2 benefit in throughput on modern GPU's. There are examples in games (anyone here ever play Kerbal Space Program?) where ingrained habits of single precision have caused noticeable problems.

[Gunnar Farnebäck]

In medical imaging, and probably most other parts of image processing with any kind of real-time expectations, single precision is used because the factor of 2 for SIMD operations is an enormously big deal, regardless whether the computations are done on a GPU or a CPU. There are pitfalls related to the limited precision but in general single precision is good enough that speed is much more important. In fact it's not unheard of going down to 16-bit fixed precision in specific computations to get even more out of the SIMD registers.

So yes, there are substantial (or at least non-trivial) parts of the Julia target audience that need single precision floats. As others have noted, this is completely unrelated to 32 or 64 bit architectures and the width of the Int type.

[Júlio Hoffimann]

Just to be clear, no one in here is arguing that Float32 is useless. The only proposal is to have a cleaner symbol Float as an alias to Float64.

Júlio.

[Simon Byrne]

One benefit of Float64 vs Float is that it helps make clear what a floating point number actually is: 64 bits. It can't represent all possible real numbers, and that's why we have things like 0.1 != 1//10.

I don't think typing the extra "64" is an undue burden: for most code using Number, Real, FloatingPoint types are typically sufficient for dispatch, and if you are dispatching on different floating point types, the bit-length would probably be useful for clarity. A grep shows that "Float64" occurs only 750 times in all of the Base library, and that includes its definition and lots of external library calls (like libmath and LAPACK calls) which most people won't encounter.

The main reasons I typically use Float64 in non-library code are for creating blank arrays using Array(Float64,m,n), and explicit conversions on comprehensions Float64[f(x) for x in X]. There might be arguments for making such calls simpler (such as making Array Float64 by default, as it is for zeros and ones), but I don't think the Float alias would help with this.

-Simon