3 ms·
It's not even about performance. It's about actively thinking about what data you'd be processing. Why use doubles when singles are okay? I'd sure not be using
by hvidgaard 13y ago
It's not even about performance. It's about actively thinking about what data you'd be processing. Why use doubles when singles are okay? I'd sure not be using 64 bit ints just because "it's bigger" when a normal 32 bit would be just fine.
- marcosdumay 13y ago> Why use doubles when singles are okay? Because of rounding issues, that look like a no problem for a single precision number, but will be a no problem^2 for a double precision one. Thus, if I'm wrong (or get wrong after a change in scope), the program will still work.
- cwp 13y agoWell, if you need more precision than singles provide, then yeah, use doubles. The question was, "why use doubles when singles are okay?"
- chii 13y agobut you didn't consider the other case, which imho, is more common - where you thought 1 char ought to be enough for anybody...until it isn't, and it's impossible to make it into a 32bit integer...
- hvidgaard 13y agoOnly when requirements have changed significantly, have I had to change the datatype. Either the input resolution are increased significantly, or the amount of data is several magnitudes larger than original specified, or higher precision is required. I tend to err on the side of selecting something larger if I'm uncertain. Consider a database: If expected data amounts to 10 inserts pr second, and the application lifetime is expected to be 10 years, 32-bit is enough to index. However, there is only room for 36% growth, so 64-bit it is, unless performance is important. In that case watch the index and project when it will run out of space. The point is, you consider the cases, and make an educated choice, this means reasoning about it both ways.