macOS "Optimal" width float type?

[haravikk]

Hi there,

This seems to be a difficult thing to search for, so I'm just going to have to ask instead. Basically, I'm looking for what the equivalent of an NSInteger would be for a float?

As I understand it, NSInteger is an integer whose size is that of a pointer, so on 32-bit systems that should be 32-bit, and on 64-bit systems that should be 64-bit.

I'm wondering if there's a provided value for floats that is similar; i.e - on a 32-bit system it'll be a float, but on a 64-bit system it'll be a double? I'm interested because I've found that while 32-bit can be handled just-fine on 64-bit it's not quite as efficient, and it definitely is less efficient to use 64-bit doubles on a 32-bit machine. For this reason I'd like to be always using the most efficient, as I don't require the full-range of a float let alone a double anyway.

Thanks

 

[lee1210]

I think CGFloat is "native-width", but for floating point it is not as important. Sign-extending a 32-bit value for use on a 64-bit arithmetic unit is not costly, and there is native 64-bit floating point math on all of the 32-bit chips apple has sold recently. I would say you should always use double if you need a floating point. Having the extra precision for rounding, etc. is a good thing. If you don't need that much precision, stick to ints and just assume a 2 position bias for the decimal, etc.

-Lee

 

[kainjow]

CGFloat - it's defined in CGBase.h.

 

[GorillaPaws]

I would say you should always use double if you need a floating point. Having the extra precision for rounding, etc. is a good thing.

Can you think of any "normal" situations where it would make sense to use a float or should I try to pretend they don't exist?

 

[lee1210]

Can you think of any "normal" situations where it would make sense to use a float or should I try to pretend they don't exist?

Normal, not really. For objective-C, you're already getting a lot of memory use from the runtime, object overhead, etc. You should still be frugal to a certain degree, but the few bytes you're saving using a float is probably not going to be very significant.

If you're storing a few million, and you truly don't need a lot of sigfigs, but the decimal is not fixed... that is one. Maybe not "normal", but it's not that far-fetched.

If you were using plain C, and you were in a situation where very, very little memory is available (Say, an embedded device), saving a few bytes here and there might make a big difference. Again, this is amplified if you're going to have large arrays of this type, or of a structure that contains it, etc.

I've simply spent too much time dealing with problems caused by rounding issues with floats, etc. to consider it worth the memory savings to cost yourself potential bugs. Even doubles aren't "big enough" all the time, but that's where i default.

As an aside, i work on a system with very old code, where the cost of 4-bytes in the 256-byte fixed-sized records was considered high... so i have to deal with 4-byte floating points and the inherent problems all the time, so I am prejudiced against them.

-Lee

 

[gnasher729]

Use double unless you have a very good reason to use something else.

Use float if you have tons and tons of values that all need very little in precision. float only has about six digits of precision; not very much for many purposes, and if you do lots of calculations, rounding errors add up and you get into trouble.

Use long double if double's 15 digit precision is not enough; long double gives you about 19 digits (Intel) or 30 digits (PowerPC).

Use CGFloat for graphics coordinates when you call APIs that use CGFloat. For graphics applications, float is enough 99 percent of the time, but in a 64 bit application Apple uses double for CGFloat instead of float; not because it is a 64 bit application, but because it is running on a more powerful machine.

 

[GorillaPaws]

As always Lee, your advice is greatly appreciated.