   [C#] Using double over float
  **I'm not sure if double and float are .NET keywords, but I'm using C#**Currently I'm self-teaching myself C#.  I'm studying naming different types of data by variables, and what all different types there are.In the case of Floating-Point Data, it states that double is used more often than float due to double already being 64 bits, and not having to narrow and widen the data for the coprocessor.  I get this, I understand that through larger programs dealing with large amounts of data at one time that this data narrowing and widening could slow the processes.  What I don't understand is why there is a float command AT ALL. Based on the book I'm reading there really isn't a good reason to use float, are there any examples where float would be the preferred floating-point data type?   
  The real reason double is "better" than float is because of precision. A float is almost always guaranteed to be super-unreliable, whereas a double is only slightly unreliable. When working across different systems and architectures that behave differently with floating point values, using floats is almost always a terrible idea; the discrepancies can be huge.But if you don't need the precision of a double, floats:- Are smaller, so they take up less space in memory. If you need to store/transfer a lot of floating point values, you may want to use floats.- Are smaller, so you can fit more into a single instruction. The speedup can be significant if the compiler manages to figure out how to optimize your math well enough.And I'm sure the resident bookworms will have a lot more to say :p   ;Quote:using floats is almost always a terrible idea; the discrepancies can be huge.Lets go easy on the hyperbole here...If you're building a rocketship to Mars then yeah maybe you want to use doubles in your calculation. For most situations floating point is going to be perfectly adequate.For a floating point example, look at the resoluton around 3.0. You can represent 3.0, 3.0000002, and 3.0000005.If you try to store 3.0000003 as a floating point, your number will be stored as 3.0000002. In your application are you really saying "Bah! this is incorrect by 0.0000001" (thats 0.000001% error if you're counting).I don't know if I'd call this "super-unreliable";The reason float exists at all, is offering you a choice to choose a type that best fits your data. To draw a comparison, a long can hold a much larger range than for example an int or a byte. Yet there are many scenarios where an int is already overkill and in some cases you just want to work with the tiny byte. This comparison may be a bit flawed, but the same basic idea holds for float and double.As for practical applications of floats, you've come to the right place to ask your question. A prominent application for floats would graphics. Current hardware and consequently rendering code mostly works with floats for things like model data. The float precission typically is more than enough to hold the positional information for 3D rendering, the graphics hardware is optimized for processing it and it has the major benefit of only using half the bus bandwidth compared to a double.;  floats are either awful or excellent, depending on what you are actually using them for. For some things even the half-float (16-bits) is the best choice.Your FPU probably uses 80-bit format internally. double's still need to be widened for it.   ;Quote:Original post by remigiusAs for practical applications of floats, you've come to the right place to ask your question. A prominent application for floats would graphics. Current hardware and consequently rendering code mostly works with floats for things like model data. The float precission typically is more than enough to hold the positional information for 3D rendering, the graphics hardware is optimized for processing it and it has the major benefit of only using half the bus bandwidth compared to a double.This was my concern actually, although I do not do game programming (I'm more gearing towards business utilities applications), it seems as though with double vs. float, you're trading off more virtual memory usage vs. more processing power. My target aim with my application will be an organization that uses very outdated computers, and my application that I'm currently drafting up will be rather large -- so my actual coding means will be a challenge.Based on the book, it states that while double uses twice as much memory to hold it's data in a 64-bit process, it also processes faster considering that most processors now have a coprocessor that is used specifically for processing 64-bit data, and if you use a float variable it has to take the 32-bit process that it uses, widen that data to 64-bit, let the coprocessor process the data, then narrow the data back down to 32-bit.  Which obviously takes more processing time.  So in a sense, double could cause more code bloat than float would, but I'm guessing it's just based on which performance type you can give up?**Guess I'm diving in a little deep for me just learning programming :/**   ;Quote:Original post by iMalcfloats are either awful or excellent, depending on what you are actually using them for. For some things even the half-float (16-bits) is the best choice.I was unaware there was such a thing, double uses 15 digits, float uses 7 digits - AFAIK. How many digits can half-floats store? This might actually be a better option for me due to me needing to use fractional numbers, but in business it's usually nothing larger than 2-3 digits off the decimal point.   ;Quote:Based on the book, it states that while double uses twice as much memory to hold it's data in a 64-bit process, it also processes faster considering that most processors now have a coprocessor that is used specifically for processing 64-bit data, and if you use a float variable it has to take the 32-bit process that it uses, widen that data to 64-bit, let the coprocessor process the data, then narrow the data back down to 32-bit. Which obviously takes more processing time.Doesn't usually matter.  You have to be doing a lot of tight math before you should care.Consider a particle system in a game, you have 100000 particles, and you need to add velocity.xyz to position.xyz based on time. That is 3 multiplies and 3 adds on 7 source numbers going to 3 output numbers.1 source float (for time, 1 float expand)loop 100000   6 source floats (7 float expands)  3 multiplies ( vel * time )  3 adds ( pos + vel )  3 stores (3 float truncates)OR1 source double (for time)loop 100000   6 source doubles  3 multiplies ( vel * time )  3 adds ( pos + vel )  3 stores Whats faster?The float path. Why? Memory bandwidth. The entire particle operation is super fast. The problem is feeding in enough source numbers to keep the FPU happy.  Waiting for memory can be slow, hundreds or thousands of cycles. (or billions if you got swapped to disk) Those few math operations happen in dozens of cycles.The double path takes 2x (or more) as long to feed through the same number of particles.But, the above case is optimal for streaming data through the CPU. You COULD still run into slowdowns with the float path under different conditions but it isn't as likely an issue as I think you are trying to make it out to be.Quote:How many digits can half-floats store? This might actually be a better option for me due to me needing to use fractional numbers, but in business it's usually nothing larger than 2-3 digits off the decimal point.As far as I know, this is a GPU specific feature.   ;  If you do business applications that deal with money and quantities you really should be using the decimal type (for fractional values), which was actually created specifically for this purpose. Double might be acceptable depending on the circumstances but float would be absolutely terrible.Unless you somehow end up with an application that needs to crunch billions of values as fast as possible, the performance impact of using decimal instead of double/float is going to be negligible. In my experience most heavy operations on business apps (at least the kind I deal with) are going to be limited by the database rather than raw CPU power. Clever design, caching where needed and a proper database setup (correct use of indices, etc.) has in my experience a much larger impact on application performance than micro optimizations like using smaller data types.Game/graphics programming is of course a completely different scenario - here floats should be the primary choice, as it is a precise enough data type for such purposes and a lot of graphics architecture is specifically designed to deal with masses of 32 bit values, at least from my understanding.   ;Quote:Original post by Christopher LoydThis was my concern actually, although I do not do game programming (I'm more gearing towards business utilities applications), it seems as though with double vs. float, you're trading off more virtual memory usage vs. more processing power. That would depend on the hardware. It might hold true for your processor (CPU), but for graphics cards (GPU) a float offers both benefits. That is, on graphics hardware a float is both faster to process and saves memory/bandwidth. I'm not in the know about the current state of floating point optimizations for the CPU, but I always understood their effectiveness was tricky at best, especially when used from .NET, so your processing power argument may not hold.Case in point: if you really need to worry about floating point performance implications this much, it'd probably be worth exploring your options for GPGPU or specialized SSE math libraries. However I suspect you're being overly prudent in your performance considerations.Quote:My target aim with my application will be an organization that uses very outdated computers, and my application that I'm currently drafting up will be rather large -- so my actual coding means will be a challenge.A large application doesn't necessarily mean performance or resource intensive. That's governed by the size of the data set you need to keep in memory and the number of computations you're expecting to carry out. Designing your program to keep those characteristics in check is probably much more worthwhile than worrying about micro-optimizations like floating point performance up-front.Quote:**Guess I'm diving in a little deep for me just learning programming :/**There's nothing wrong with taking a deep dive, but you may be a bit too much on theoretical ground at the moment. Even if all your concerns hold true, it remains to be seen if it really is an issue for your application. I personally never worry much about floating point performance and just use them where they seem an appropriate fit for my data and/or hardware. Quote:As far as I know, this is a GPU specific feature.That's pretty much spot on. XNA has some 16 bit floating point types (in the Graphics.PackedVector namespace) but these cannot be not processed 'natively'. They don't support any operations but need to be converted to floats for processing. This is probably my only adventure in floating point optimizations, since these 'half' types save tremendously on bus & sampler bandwidth. This is obviously only useful when you're trafficing loads of data to and from the GPU. 