#define and preprocessor magic

[Joe Pfeiffer]

(Drill bits come in 1/16, 3/32, 1/8, 5/32, 3/16, 7/32, 1/4 inch.
Biggers sets in multiples of 1/64th inch. All nice binary fractions.

Except for the numbered bit sizes -- and I've got no idea in the world
how those got established.

 

[Ben Bacarisse]

Except for the numbered bit sizes -- and I've got no idea in the world
how those got established.

....and also except for mm sizes in Europe (and quite possibly many other
places) though they are, in some sense, "nice binary fractions" since
they are usually whole numbers with the occasional .5 thrown in.

 

[Greg Martin]

Except for the numbered bit sizes -- and I've got no idea in the world
how those got established.

It's so you can have three fits for each size hole: close, normal and
loose. The fractional sizes don't allow for that. There's actually a
specification for it (of course). Much of the world used the system but
with the accuracy of metric sizes it has gone out of favour outside of
the US. A bag of 8 penny nails anyone?

 

[ralph]

Your point about small units being divided is a good one, but it's the
very fact that you can add any number of units easily that has given
rise to these crazy systems -- crazy because there's a factor of 11 in
there.

The key to the mile is actually the furlong -- it was defined by statute
to be eight furlongs, with a furlong being 40 poles. All sane(ish)
except that a pole is 16 1/2 feet. Yes, 16 1/2. It's that 16 1/2 gives
rise to the 11 .

When it came to determining where to start measuring off your poles,
or dividing up your acre - one used a chain. Your county surveyor or
large land owner had a chain. Your average farmer had a "pole" and
"yardstick" about.

Interestingly, a chain was built of a 100 links, probably because one
counted them as they rolled off the wagon.

-ralph

 

[Phil Carmody]

I get:

300.029999999999970000000000000000000000000000000

using (mingw) gcc 4.5.0 on Windows. I'd prefer to get what you did..

Maybe stop using a second-rate OS with a crappy libc? It's within
the accuracy bounds demanded of the library, but IMHO is not a
useful string to output. It looks like it's just capping the
output at 17 significant digits.

However DMC gives:

300.029999999999972710000000000000000000000000000

It looks like %.__f is turned into %.17f for all __ > 17?

a few extra digits (but it seems incorrectly rounded down on the last
digit). And Pelles C gives:

300.029999999999953433870000000000000000000000000

I'm not sure I can work out what went "wrong" there. Do you get a
round-trip error from that expression when scanf-ed back in (to
any implementation)? I've not looked at the lowest bits in its
representation, but I think it should be OK - my ppc treats it
as the same value as 300.03 (anything above 300.029999999999945
is OK it seems).

which is not quite right. Finally, lcc-win32 gives:

300.030000000000000000000000000000000000000000000

which is either wildly inaccurate, or the only one that is spot on!

Well, it's not wildly inaccurate, as it's accurate to 17 digits, which
is all that is demanded of the library. However, the number you are
attempting to print out is 300.029999999999972715158946812152862548828125
and you have to ask yourself how you would want that number to be
printed. This is a different question from how you would want 300.03 to
be represented, of course.

I've got to admit, I certainly prefer the glibc output in all cases.

Phil

 

[Fred J. Tydeman]

Presumably you mean %La -- using %a for long double is, technically,
undefined.
Correct.

Can you give an example (with the glibc version number) because a quick
test of my own (with glibc 2.13.1) does not find any round-trip errors.
Also, it's possible the problems are related to older hardware. I'm
using a 64-bit Intel architecture.

Hardware: Intel Core i5-64
O. S.: Linux Fedora Core 17 (64-bit mode)
Compiler: gcc-4.7.2-2.fc17 (64-bit)
Library: glibc-2.15-57.fc17 (64-bit)

Starting with the value:
ld1=000000000000000022b5=+3.238759784077578684346488672020854507e-4947
And using swprintf() with the format L"%-+#La" produces:
buf='+0x0.00000000000022bp-16385'
Then using either swscanf() or wcstod() on that buffer gets:
ld2=0000000000000000022b=+2.023085740194773404403265293158777998e-4948

So, you can see, the round trip from internal floating-point
to string via %La and back to internal floating-point has errors.
---
Fred J. Tydeman Tydeman Consulting
(e-mail address removed) Testing, numerics, programming
+1 (775) 287-5904 Vice-chair of PL22.11 (ANSI "C")
Sample C99+FPCE tests: http://www.tybor.com
Savers sleep well, investors eat well, spenders work forever.

 

[Ben Bacarisse]

Hardware: Intel Core i5-64
O. S.: Linux Fedora Core 17 (64-bit mode)
Compiler: gcc-4.7.2-2.fc17 (64-bit)
Library: glibc-2.15-57.fc17 (64-bit)

All newer than mine and I don't see the behaviour you are getting. It
looks like a bug has crept in at some point.

Starting with the value:
ld1=000000000000000022b5=+3.238759784077578684346488672020854507e-4947
And using swprintf() with the format L"%-+#La" produces:
buf='+0x0.00000000000022bp-16385'

Presumably you got the +3.238759784077578684346488672020854507e-4947
from printf using something like "%+.37g". If so, it would seem that
printf can get the more complex output right but not the simpler one.

If my calculations are correct, the decimal is correct but obviously the
hex output is wrong.

0x0.00000000000022b5p-16385 is a denormal, but I don't think that
explains anything. It works on my system and the decimal output is
correct on yours.

Then using either swscanf() or wcstod() on that buffer gets:
ld2=0000000000000000022b=+2.023085740194773404403265293158777998e-4948

This bit looks correct. I really would have expected the error to be on
input not output, but then I should have stopped being surprised by bugs
a long time ago.

So, you can see, the round trip from internal floating-point
to string via %La and back to internal floating-point has errors.

Yes, but it's a bug rather than an intrinsic problem with the
technique. Of course, the presence of a bug makes the technique
unreliable. Has it been reported as far as you know?