floor((percentage / 10) – 5)

but for 100% it gives 5 so needs and extra check afterwards to subtract 1 in this case. I can’t think of a way of eliminating this problem. (Unless you want to assume nobody ever gets 100%…!)

Here are some examples:

floor((100 / 10) – 5) = 5 <= NEED TO SUBTRACT 1

floor((90 / 10) – 5) = 4

floor((89 / 10) – 5) = 3

floor((80 / 10) – 5) = 3

floor((79 / 10) – 5) = 2

floor((70 / 10) – 5) = 2

floor((69 / 10) – 5) = 1

floor((60 / 10) – 5) = 1

floor((59 / 10) – 5) = 0

I think if you add a number to tm_mday and then call mktime to get a time_t it will adjust the date by wrapping it round if it overruns the end of the month.

]]>If you do this:

f = 100.0;

max = nextafter(f, 101.0);

min = nextafter(f, 99.0);

printf(“%e max is\n%e\n%.64lf\n\n”, f, max, max);

printf(“%e min is\n%e\n%.64lf\n”, f, min, min);

you get this:

1.000000e+02 max is

1.000000e+02

100.0000000000000142108547152020037174224853515625000000000000000000

1.000000e+02 min is

1.000000e+02

99.9999999999999857891452847979962825775146484375000000000000000000

The two outputs with %e are too small for the differences to show up but with %.64lf you can see numbers a tiny bit higher and lower than 100.

In some languages or environments you can retrieve a value called Epsilon which is the smallest representable value, although with C it seems you have to get it indirectly using nextafter.

I think it is used to compare real numbers for equality while allowing for floating-point formats like IEEE 754 not being able to store all decimals with exact precision. Something like that anyway.

]]>Obviously, whoever is coding the function knows about *restrict* and how to best use it.