Oh, and I see another bug in the output of my
celsius-to-fahrenheit converer program, that I posted about
here a few minutes ago (re. extra blank lines form printf).

Again, the main lines are:

   printf("    Cels        Fahr   \n");

   for (Cels = CelsMin; Cels <= CelsMax; Cels += CelsInc)
   {
      Fahr = (((Cels*180.0)/100.0)+32);
      printf("%10.3f   %10.3f\n\n", Cels, Fahr);
   }

and the output for "celsfahr 40 41 0.001" is (sans extra blank lines):

    Cels        Fahr
    40.000      104.000
    40.200      104.360
    40.400      104.720
    40.600      105.080
    40.800      105.440

Where is 41.000 ???  This table should have 6 entries, not 5,
and the last line should read:

    41.000      105.800

Looks like the <= comparison is failing when Cels gets up to 41.000.
I'm guessing it's somehow gets off a very small amount.  Perhaps
it's 41.00000001 when it gets compared to 41, so <= return false.

I could change "Cels <= CelsMax" to "Cels <= (CelsMax+0.0001)".
But that's a bit ugly.  Any simpler way to do this?

   int a,b,c,d,e,f;

I've known programmers that do that.  In production code,
for mid-sized corporations, no less.  Grrr!

If you really need to do this, do all the loop controls in integer math,
then convert at the last minute using a fixed scale factor.  e.g.,
loop up to 205, then divide by 5 inside the loop.

The <= issue is also now fixed.  I used a +0.0001 "fuzz zone".
(See other post.)

In addition to the other advice you've gotten, it might be instructive
to print the values to greater precision.  Since you stated a new
thread, I can't find the article containing your actual code without
more effort than I'm willing to expend.  But here's a program based on
the snipped above, which allows you to vary the precision of the
output via a command-line argument.  Try it with increasing values of
"digits".  On my system, things start to get interesting around
digits==14.

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
    const double CelsMin = 40.0;
    const double CelsMax = 41.0;
    const double CelsInc = 0.2;
    double Cels;
    double Fahr;
    int digits;

    if (argc >= 2) {
        digits = atoi(argv[1]); /* crude, but ok for now */
    }
    else {
        digits = 2;
    }

    printf("CelsMin = %.*f\n", digits, CelsMin);
    printf("CelsMax = %.*f\n", digits, CelsMax);
    printf("CelsInc = %.*f\n", digits, CelsInc);

    for (Cels = CelsMin; Cels <= CelsMax; Cels += CelsInc) {
        Fahr = Cels * 180.0 / 100.0 + 32.0;
        printf("Cels = %.*f  Fahr = %.*f\n",
               digits, Cels, digits, Fahr);
    }
    printf("After loop, Cels = %.*f\n", digits, Cels);
    return 0;

Control your loop with an integer, not a floating-point variable.

Read "What Every Computer Scientist Should Know About Floating-Point
Arithmetic" by David Goldberg.

What is the true value of CelsInc?  Hint - it is not numerical value
0.2 that you think it is.

This "fuzz zone" approach can work well with much less code bloat
than the "convert-to-integers" method, PROVIDED that you can find
a fuzz value that is at least an 2 magnitude smaller than the
"granularity" of the numbers involved, and 4 orders of magnitude
larger than the floating-point errors involved.  In some cases,
that can't be done, and you have to use "convert-to-integers".
But In the case of my temp conversion programs, a suitable
fuzz value was very easy to find, because the granularity is
known.

(So why was I even asking about this here, if I already know
these two methods?  Simple: I was wondering if anyone knew
any *OTHER* methods I hadn't considered.)

Oh, and you *STILL* have to use a "fuzz zone", to avoid converting
to the next lower integer.  Think about it!  If you use an "expand
by 1000" technique, you want 0.1999999999 to expand to 200, not
199.  So you have to fuzz it by adding 0.01 to all your expansions
after multiplying by 1000 but before casting to int.  Else you're
right back to "Equality failure of <= operator".

(Why 0.01?  Two orders of magnitude below 1, and about four orders
of magnitude above the x1000 expanded floating-point errors.)

If I used the "convert-to-integers" method for my temp-conversion
programs, they would have to look something like the folowing
(untested) code:

========= BEGIN "CONVERT-TO-INTEGERS" METHOD ======================

   double cels_min_flt = atof(argv[1]);
   double cels_max_flt = atof(argv[2]);
   double cels_inc_flt = atof(argv[3]);
   int    cels_min_int = (int)(1000.0 * cels_min_flt + 0.01);
   int    cels_max_int = (int)(1000.0 * cels_max_flt + 0.01);
   int    cels_inc_int = (int)(1000.0 * cels_inc_flt + 0.01);
   int    cels_val_int = 0;
   double cels_val_flt = 0.0;
   double fahr_val_flt = 0.0;

   printf("    Cels        Fahr   \n");

   for
      (
         cels_val_int  = cels_min_int; /* initialize    */
         cels_val_int <= cels_max_int; /* crisp-compare */
         cels_val_int += cels_inc_int  /* increment     */
      )
   {
      /* We're past the "<=" hurdle, so convert back to double: */
      cels_val_flt = ((double)cels_val_int)/1000.0;

      /* Now continue with calculation in floating-point: */
      fahr_val_flt = (((cels_val_flt*180.0)/100.0)+32);

      /* And, finally, print the results: */
      printf("%10.3f   %10.3f\n\n", cels_val_flt, fahr_val_flt);
   }

========= END "CONVERT-TO-INTEGERS" METHOD ======================

And we have achieved... WHAT, exactly?  Massive code bloat,
monstrous unclarity of code, and huge potentials for maintainance
errors.

Now, compare with *my* approach, which uses *no* conversions,
just a single 0.00001 fuzz value:

======== BEGIN "FUZZ-ZONE" METHOD =======================

   double cels_min = atof(argv[1]);
   double cels_max = atof(argv[2]);
   double cels_inc = atof(argv[3]);
   double cels = 0.0;
   double fahr = 0.0;

   printf("    Cels        Fahr   \n");

   for
      (
         cels  = cels_min          ; /* initialize    */
         cels <= (cels_max+0.00001); /* fuzzy-compare */
         cels += cels_inc            /* increment     */
      )
   {
      fahr = (((cels*180.0)/100.0)+32);
      printf("%10.3f   %10.3f\n", cels, fahr);
   }

======== END "FUZZ-ZONE" METHOD =======================

*Much* simpler and more efficient, due to no conversions.
Much more clear and understandable.  Much easier to maintain.

The appropriate fuzz value of 0.00001 ensures that "<=" always
does what we want it to, thus achieving everything that the
"integers" method does, without all the bloat and confusion.

I'm quite aware that at the realm of about 1 part in 1E10,
there are errors in the internal representations of floating point
numbers.  There's only a finite number of bits, after all, and many
real numbers need an infinite number of bits to exactly represent them:
1/3 = 0.3333333333...(to infinity)   (can't be represented exactly)
pi  = 3.1415926535...(to infinity)   (can't be represented exactly)

But as for 0.2, I'm not sure why it can't be exactly represented.
Perhaps you can enlighten?

Let's try that....

/* zero-point-two.c */
#include <stdio.h>
int main(void)
{
   const double zero_point_two = 0.2;
   printf("zero_point_two = %.40f\n", zero_point_two);
   return 0;

It's showing errors starting at 1E-17.

Not sure, however, just how much of that is in the number itself,
and to what extent it's due to printf()'s limitations.  But one
thing is clear: if *ANY* of those non-zero digits to the right
of "0.2000000000000000" are actually being stored in the variable
"zero_point_two", then it will cause exactly the bug I was
having.  And clearly my fuzz value of 0.00001 is perfect:
far below granularity of 0.001, but far above error value
0.000000000000000011102230...

ADDENDUM:

Out of curiosity, I expanded the display of 0.2 to 60 digits:

/* zero-point-two.c */
#include <stdio.h>
int main(void)
{
   const double zero_point_two = 0.2;
   printf("zero_point_two = %.60f\n", zero_point_two);
   return 0;

So printf() doesn't print random gibberish at any point;
it either print's what's there, or it prints 0 if nothing
is there.

Hence, the actual ammount of error in the double-precision
floating-point representation of 0.2 on my system & OS & compiler is
0.000000000000000011102230246251565404236

WHich explans why
   40.0 + 0.2 + 0.2 + 0.2 + 0.2 + 0.2
   == 41.00000000000000005551115123125782702118
    > 41.0

BUT,
41.000000000000000055511151231257827021180 < 41.00001
AND
41.200000000000000066613381477509392425416 > 41.00001

--
Cheers,
Robbie Hatley
lonewolf at well dot com
www dot well dot com slant tilde lonewolf slant

0.200000000000000011102230246251565404236316680908203125000000

snip

For example, 0.375 * 2 = 0.75; keep the 0.  0.75 * 2 = 1.5; keep the
1.  0.5 * 2 = 1.0; keep the 1 and stop.  The binary representation of
0.375 is 0.011.

Now try it with 0.2 and let me know when the process terminates.