Arithmetic
in [Java Programming]
|
Prev: Possible easy diagnostic outputting from multiple threads tothe one text frame
Next: JDK 1.6.0_21 released
From: Lew on 10 Jul 2010 12:47 blmblm(a)myrealbox.com wrote: >>> (I'd agree with your later post that numerical analysis is a big CS >>> topic, and one worthy of study, but I'm not sure I'd agree with a >>> claim that it's something all programmers should be experts about.) Lew wrote: >> Huh? I never said that. blmblm(a)myrealbox.com wrote: > And where did I say you did .... Sorry if I wasn't clear: And where did I say you said I said that? :-) The problem is the implications in the syntactic structure "I agree with you that ..., but ...", whereby the "but" clause sets up a straw man for the other's argument. > I originally wrote "I'm not sure I'd agree that it's something ....", > realized that I wasn't sure you'd made such a claim, rewrote, > and .... Still didn't communicate clearly! I guess I should have > said explicitly that I wasn't saying you were making such a claim, > rather than hoping that saying "a claim" rather than "your claim" > would convey my intended meaning. "Whatever"? You're absolutely right. I guess I should've said explicitly that I wasn't saying you were making such a claim, rather than hoping that saying "I never said that" would convey that I was speaking to others who might misconstrue. Once again, :-) I actually did understand that you'd made the "a claim" vs. "your claim" distinction, albeit after I pressed SEND, but figured that if I could misunderstand so could others, and chose to wait to press the point home once you inevitably corrected me. My concern is that computer programmers know the basics. That's all I've advocated in this discussion. One need not be a numerical analysis expert to be aware that floating-point representation is an approximation to real numbers, and that Boris Punk's "missing" 111111s are a consequence of limited precision. One does need at least to be aware of those limits to lay claim to be any kind of professional programmer. Kudos to you as an educator that you take the care to include fundamentals such as the limitations of floating point in your curricula. Would that all educators were so diligent! -- Lew Would that English had the subjunctive!
From: Martin Gregorie on 10 Jul 2010 13:51 On Sat, 10 Jul 2010 12:47:32 -0400, Lew wrote: > Kudos to you as an educator that you take the care to include > fundamentals such as the limitations of floating point in your > curricula. Would that all educators were so diligent! > My first language was and Eliott 503 dialect of Algol 60 . I don't remember being taught much detail about real number representation other than the number of significant digits it could handle (The Eliott used single word values in a 39 bit word) and that real number representatin wasn't always exact, but I do remember it being hammered in that equality should *never* be used to compare real numbers: instead compare the difference with a domain-specific limiting value. If both values are known to have the same sign then "if a - b < 0.005 then ....;" would be appropriate if the values are known to be accurate to two decimal places. I'd always assumed that all programmers are taught this much about dealing with floating point numbers regardless of what the language calls the type(s). Am I wrong in this assumption? -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Jim Janney on 10 Jul 2010 14:32 Martin Gregorie <martin(a)address-in-sig.invalid> writes: > On Fri, 09 Jul 2010 16:05:39 -0600, Jim Janney wrote: > >> >> In practice there's a strong tendency toward whatever the programming >> language makes convenient. The system I work with was originally >> written in RPG. RPG strongly favors fixed point decimal, and that's >> what is mostly used in the RPG code and in the data base, for example 9 >> digits with 2 decimal places for dollar and cent amounts and 5 digits >> with 5 decimal places for interest rates. In Java we have USD and >> Percent classes that use BigDecimal internally. >> > Actually, that owes as much to the prehistoric IBM hardware that RPG was > initially designed for - most small S/360s, e.g. 360/30 and smaller (S/3, > S36, etc.) had no floating point available and many of them could only do > BCD arithmetic. The really small ones used a 4 bit serial adder. > Performance was terrible but there was no hardware limit to the number of > digits that composed a number. > > Before that very few, if any, general purpose 2nd generation mainframes > had floating point hardware - that was restricted to 'scientific' > computers such as the Elliott 503. > >> Using integers for currency amounts is numerically sound but relies on >> the programmer to keep track of the decimal position. Not bad for small >> projects but it would make me nervous for larger projects where there's >> significant turnover among the programmers. >> > That is a good reason for holding currency amounts in binary pence/cents > rather than fixed decimal dollars/pounds - decimal tracking is only an > issue when amounts are being converted to/from strings - tracking the > decimal point is largely a non-issue, even in assembler. > > COBOL solved the problem another way - even when I first used it in 1969 > the language had a COPY verb to pull in record definitions, etc. from a > source code library. There's no real equivalent in other languages and > certainly not in Java - COPY falls somewhere between C's use of #define > in header files and a decent macrogenerator. Yes, some of the code was originally written for the S/36. But the reason these implemented decimal arithmetic in hardware is that they were designed for the business and financial market. -- Jim Janney
From: Arved Sandstrom on 10 Jul 2010 15:19 Martin Gregorie wrote: > On Sat, 10 Jul 2010 12:47:32 -0400, Lew wrote: > >> Kudos to you as an educator that you take the care to include >> fundamentals such as the limitations of floating point in your >> curricula. Would that all educators were so diligent! >> > My first language was and Eliott 503 dialect of Algol 60 . I don't > remember being taught much detail about real number representation other > than the number of significant digits it could handle (The Eliott used > single word values in a 39 bit word) and that real number representatin > wasn't always exact, but I do remember it being hammered in that equality > should *never* be used to compare real numbers: instead compare the > difference with a domain-specific limiting value. If both values are > known to have the same sign then "if a - b < 0.005 then ....;" would be > appropriate if the values are known to be accurate to two decimal places. > > I'd always assumed that all programmers are taught this much about > dealing with floating point numbers regardless of what the language calls > the type(s). Am I wrong in this assumption? It's not real numbers and equality that's problematic - it's their floating point representation. If I undertook to carry out all my real number computations with rational numbers then at any point I'd be able to decide in my program whether real number a was equal to real number b. AHS -- The warning message we sent the Russians was a calculated ambiguity that would be clearly understood. -- Alexander Haig
From: Martin Gregorie on 10 Jul 2010 16:24
On Sat, 10 Jul 2010 12:32:33 -0600, Jim Janney wrote: > > Yes, some of the code was originally written for the S/36. > System/360 actually. RPG first appeared on the bottom 360/20 and 360/30 models as a COBOL alternative in the late '60s. The improved RPG II appeared on System/3 when it was launched 5 years later and was ported to the S/32, S/34 and S/36 when these were launched. RPG III came in with the S/38, later re-launched with 2nd gen hardware as the AS/400. > But the reason these implemented decimal arithmetic in hardware is > that they were designed for the business and financial market. > They could have equally well implemented normal integer arithmetic and ignored BCD. The contemporary ICL 1900 series of mainframes did just that. Both ranges omitted hardware floating point from the smaller machines or, at best, made it an optional extra. The bigger S/360s had 32 bit registers but the 'small business computers' only used BCD arithmetic because implementing a 4 bit register + carry ALU and only supporting BCD number representation was so much cheaper than building a 32 bit ALU given the primitive integrated circuits of the era. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | |