Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > #define and preprocessor magic

Reply
Thread Tools

#define and preprocessor magic

 
 
Joe Pfeiffer
Guest
Posts: n/a
 
      11-17-2012
glen herrmannsfeldt <(E-Mail Removed)> writes:
>
> (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.
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-18-2012
Joe Pfeiffer <(E-Mail Removed)> writes:

> glen herrmannsfeldt <(E-Mail Removed)> writes:
>>
>> (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.


....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.

--
Ben.
 
Reply With Quote
 
 
 
 
Greg Martin
Guest
Posts: n/a
 
      11-18-2012
On 12-11-17 01:56 PM, Joe Pfeiffer wrote:> glen herrmannsfeldt
<(E-Mail Removed)> writes:
>>
>> (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.
>


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?

 
Reply With Quote
 
ralph
Guest
Posts: n/a
 
      11-18-2012
On Sat, 17 Nov 2012 19:25:03 +0000, Ben Bacarisse
<(E-Mail Removed)> wrote:

>ralph <(E-Mail Removed)> writes:
><snip>
>> The key to the mile is not the feet/mile but yards to mile (1760).
>> That gives use 880 yards to a half section. 440 yards to the quarter,
>> ... . All easier to mark off using the simple tools of the time.

>
>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
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      11-18-2012
"BartC" <(E-Mail Removed)> writes:
> "Phil Carmody" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > "BartC" <(E-Mail Removed)> writes:

>
> >> Why doesn't it print the right value?

> >
> > Probably a c library issue. What does
> > printf("%30.45f\n", 300.03);
> > give you?
> >
> > gcc 4.4 on my linux/powerpc gives
> > 300.029999999999972715158946812152862548828125000
> >
> > The exact value is
> >
> > ? 5278183578906132/2^44.
> > 300.0299999999999727151589468121528625488281250000 0

>
> 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
--
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.
 
Reply With Quote
 
Fred J. Tydeman
Guest
Posts: n/a
 
      11-18-2012
On Fri, 16 Nov 2012 16:40:11 UTC, Ben Bacarisse <(E-Mail Removed)> wrote:

> "Fred J. Tydeman" <(E-Mail Removed)> writes:
>
> 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.2387597840775786843464 88672020854507e-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.0230857401947734044032 65293158777998e-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
http://www.velocityreviews.com/forums/(E-Mail 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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      11-18-2012
"Fred J. Tydeman" <(E-Mail Removed)> writes:

> On Fri, 16 Nov 2012 16:40:11 UTC, Ben Bacarisse <(E-Mail Removed)> wrote:
>
>> "Fred J. Tydeman" <(E-Mail Removed)> writes:
>>
>> 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)


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.2387597840775786843464 88672020854507e-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.0230857401947734044032 65293158777998e-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?

--
Ben.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Preprocessor magic needed claus.tondering@gmail.com C++ 8 03-20-2006 10:52 AM
Preprocessor magic needed claus.tondering@gmail.com C Programming 8 03-20-2006 10:52 AM
Compiler error occurred when try to use a flexible template expression in preprocessor definesCompiler error occurred when try to use a flexible template expression in preprocessor defines snnn C++ 6 03-14-2005 04:09 PM
preprocessor, token concatenation, no valid preprocessor token Cronus C++ 1 07-14-2004 11:10 PM



Advertisments