On Sun, 23 Oct 2011, Tony Duell wrote: In many cases, "REAL" (actually "floating point") numbers are inappropriate. For MONEY, I tried to get my students to use ints (and calculate the pennies not the dollars), and then just move the PERIOD when they display the results.

On 23 Oct 2011 at 16:55, Toby Thain wrote: Any calculation where the decimal point is movable is "floating point", even if said number is not in exponential notation. The two are not the same, even though the terms are often confused. Early calculators that would simply shift the point one way or the other in a field of significant digits is an example of floating point, but not exponential notation. --Chuck

On 23 Oct 2011 at 19:54, Toby Thain wrote: Regardless, I was referring to the old, almost forgotten "floating decimal point" sometimes found on old calculators and in early computer programs. There, the point moves anywhere within the significand, but not outside of it. For example, if you have a 4 digit device, a floating point can express values between .0001 and 9999. No exponent to extend the range of absolute values. Fixed point, in the same sense only means that the decimal point is anchored to a particular position; e.g., 12.34 is a fixed-point number with the point fixed between the two high-order digits and the two low-order digits. It's a shame that just about all the web has on "floating point" is about exponential/scientifc notation, which is not strictly the same-- including the screwball notion that "fixed point" somehow means "integer". --Chuck

On 23 Oct 2011 at 21:32, David Riley wrote: I don't care if the radix is 2, 10 or 13. What is normally termed "floating point" is a slight misnomer. If you will, a floating point can move within the mantissa, but not outside of it. i.e. it can have the position +/- logx(n), where n is the number of digits in base x of the mantissa. What's normally called "floating point" in the computerish sense, allows the point to move far outside of the number of digits in the mantissa. Just a minor point (pun intended). I'm sure that if you do much microcontroller or integer DSP work, you use a lot of non-integer fixed point math in the form of scaled integers. It's interesting that while some vendors seem to be intent on dropping decimal support on CPUs, there are others proposing decimal co-processors-- and the POWER6 and 7 CPUs have always had decimal floating point capabilities. --Chuck

On 24 Oct 2011 at 9:07, Fred Cisin wrote: I call it "exponential" notation. "Scientific" notation is also fairly descriptive. FORTRAN's "real" is a convenient, if not accurate, shorthand. On an aside, does anyone remember the proposal (I don't think it went anywhere) to have the exponential part of such notation also be logarithmic? The idea was that dynamic range would be greatly increased, with greater precision in values near unity. --Chuck

On 24 Oct 2011 at 10:42, Fred Cisin wrote: Or that "arithmetic" doesn't work. a+b+b+b+b+b+b is not the same as a+6.*b and so forth. If the magnitudes of a and b are sufficiently different, the result of the first may well be a; while the second will be something other than a. Trigonometric functions are in a world of their own. Woe to the programmer that thinks that acos() always returns values with the same accuracy across the full range of arguments. --Chuck

On Mon, 24 Oct 2011, Chuck Guzis wrote: I would not have been able to make a 4K TSR for calculating California sales tax based on ZIPCODE, using COBOL. Few people can write machine language in COBOL. When I had to write a Windoze version, size was no longer a major constraint, so I wrote it in C (scaled ints, NO "float"!), and played games with the linker/binder to make an .EXE that would run in Windoze, but would load the 4K TSR if it was launched in DOS. (Hint: using the Microsoft "examples", look at STUB.EXE) I intended, but didn't get around to, modifying it further, so that the same .EXE could also be run/loaded as a fake device driver by CONFIG.SYS to load the TSR lower in RAM to be able to be able to use INTRA-segment pointers to the BIOS data area (for easier keyboard buffer access) COBOL was tempting for the Windoze executable. My USUAL uses for the BCD arithmetic codes (DAA, AAM, etc.) are STILL mostly for decimal/ASCII, hexadecimal/ASCII conversions (without a conditional jump!).

On Oct 23, 2011, at 4:25 PM, Fred Cisin wrote: Which is part of why VisiCalc appeared on the Apple II first; the 6502 had a built-in "decimal" mode which did the calculations in BCD, which was a huge boon for business calculations. I seem to recall the full POWER instruction set (not the subset used on PowerPC) has a number of decimal operations as well. - Dave

I absolutely agree with you. I should have used clearer wording last night, I was using the term 'real numbers' in the mathematical rather htan computing sesne (real, as opposed to complex, numbers, the integers are of course a subset of the reals), Although IIRC some compound interest calculations require you to work to an accuracy of better than 1 penny/cent. Actually, I rarely use the term 'real number' to mean 'floating point number'. In hardware you always talk aboput a 'floating point coprocessor' (never a 'real number coprocessor'). The high level language I used the most at the moment is C, which of course declares such variables with the 'float' keyword. -tony

Am 23.10.2011 21:12, schrieb Tony Duell: This is actually the domain of more general computer algebra systems, like Mathematica or Maple. The point is not the 'i' (mathematical) vs. 'j' (EE) naming convention, but the fact that complex numbers are just a subset of similar mathematical concepts (google for quaternions or Cayley numbers) which seem to be important with Quantum Theory. The mathematics behind easily exceeds what ordinary spreadsheets can handle, and makes such an "engineer's spreadsheet" a rather limited concept. Regards -- Holger