Hi ! This is just to report something which surprised me, and which may perhaps be a very small bug ( or possibly just me being dumb ). I was using WinHugs as a calculator. From the main command prompt in WinHugs, I typed the following: 102.0*201.0 + 103.0*202.0 + 102.0*201.0 +102.0*202.0 + 102.5*200.5 I then hit 'return', and was presented with the answer: 102965.0 Now, the actual answer is 102965.25, as Hugs itself knows; when I typed: $$ - 102965 and hit 'return', I duly got the answer: 0.25 I tinkered around with a few other numbers, and what seems to be happening is that Hugs is rounding the calculation result up or down, in the way that you'd expect if you were only showing a specific number of significant figures. This seems reasonable ( although only 6 significant figures seems a bit on the low side ), but it's rather misleading to then show the '0' after the decimal point ! I'd be interested to hear your comments. Thanks for your ( hoped for ) advice on this. Yours sincerely, Iain McNaughton. -- Iain McNaughton
On Thu, Jun 28, 2001 at 02:57:48PM +0100, Iain McNaughton wrote:
I was using WinHugs as a calculator. From the main command prompt in WinHugs, I typed the following:
102.0*201.0 + 103.0*202.0 + 102.0*201.0 +102.0*202.0 + 102.5*200.5
I then hit 'return', and was presented with the answer:
102965.0
Indeed, you get that answer if you type 102965.25, which is somewhat confusing. Hugs is converting this to a string with sprintf %g, which yields "102965". It can't print that out because it looks like an Int, so it appends ".0". This only happens if there are 6 digits before the decimal point. (It also does changes 4e+5 to 4.0e+5, but that can't go wrong like this.) All this is in floatToString in machdep.c. A hack-around is to change the line if (buffer1[i]!='.') { to if (buffer1[i]=='\0') { sprintf(buffer1,"%.1f",fl); i = j = 0; } else if (buffer1[i]!='.') {
participants (2)
-
Iain McNaughton -
Ross Paterson