I’m not holding my breath though. You appear convinced that the field of Computer Science holds no secrets to someone with your immense breadth and width of varied, professional programming experience in various paradigms and many substantially different languages, and that someone stating you do not understand arguments made is merely territorial and, what was it, a “sloth”.

In banks you won’t find much floating point except in on the spot calculations (and those will often be in Excel or something similar). The major currency data types tend to be fixed point, because of the many issues with floating point. When I did data transactions between bank departments using floating point was a sure way to get a stern talking to, even if it wasn’t a firing offense like attaching a Linux system to the network was. Interesting times. There are exceptions of course, and (at least previously lucrative) business ideas built up around the limitations that cause.

You definitely need to get out more. I see a fair amount of scientific data processing code (and have written some of it myself) which doesn’t fall into either of these two categories. Lots of people who write such code for a living still use FORTRAN, but it’s not the same FORTRAN that was used in the 1960s and 1970s. Others use C, which actually does quite well for a naive user, or some variant thereof.

Floating point useless in finance? Let me give you one equation: y = y0 * (1+r/100)^n. That’s the formula for compound interest over n periods with a percentage interest rate per period of r. I’m sure it’s possible to code an integer arithmetic version of that, but it’s much more straightforward to do it in floating point. Some applications, like bank balances, make sense as integers, but floating point arithmetic has its place.

Yes, floating point arithmetic has the limitation of not being able to represent every number exactly. There are standard techniques for minimizing that error and not quoting results to unjustified precision. That’s the whole reason behind double precision, and if that’s not good enough there are ways to implement arbitrary precision.

Which doesn’t mean core languages can’t be used for that, only that it’s rare, since they’re generally ill suited.

Or in scientific data processing which is where Greg is coming from…

Aren’t you overgeneralizing a bit? Or is there no market for some dumb little book like “Numerical recipes in C”

DrMcCoy also has a valid point. Integer math is the norm in control system, real time response systems and consumer electronics, and that’s where most of today’s computers reside. Floating point math has a very limited applicability; it’s pretty much useless in control systems, finance, media decoders and the like. It’s mostly used where the inherent lack of both speed and precision is immaterial.

That may have made sense in the 1970s, when the faster execution of integer arithmetic (with integers you need only deal with the mantissa; floating-point types also have an exponent) added up to noticeable levels over the course of a program run

If you’re talking embedded programming, or even just “Apps” meant to run on PDAs or mobile phones, it still makes sense. Those devices often have no hardware support for floating point arithmetics. Doing it in software is considerably slower. And yes, it does have an impact, very audible for example in audio decoding/generation.

There’s also the problem that floats, at least using the exponent+fraction representation (as used in most hardware floating point units), in general: They can’t represent every possible non-integer value. Often, it doesn’t matter, but in certain cases, those inaccuracies add up, screwing everything up. There’s different ways of storing float values, but they either suffer from similar problems or are significantly slower. Or both.

The difference is that BASIC uses floating-point as its default numeric type. Most other programming languages default to integer arithmetic. That may have made sense in the 1970s, when the faster execution of integer arithmetic (with integers you need only deal with the mantissa; floating-point types also have an exponent) added up to noticeable levels over the course of a program run. Today, it’s often user hostile: your average user is accustomed to spreadsheets which also treat 2/3 as a floating point operation, not a trained programmer accustomed to thinking in terms of integer arithmetic.

The version of BASIC I used (for the Commodore 64) actually did provide an integer type, but I never used it. To make an integer variable you had to append a certain character (I think it was %) to the variable name, much as you had to append a $ to the name of a string variable. Having had no formal training at that point, I didn’t understand why someone would purposely choose the more restrictive type.