[SOLVED] calculating lists of dollar amounts (off by a few pennys) ?

schneidz · 07-02-2024, 01:35 PM

ennee way ī ken get this code to act rite ?:

Code:

schneidz@lq> cat s.c
#include <stdio.h>

main()
{
int i;
float s = 4.18;

i = s * 100;
printf("float s = %f :: int i (s x 100) = %d\n", s, i);
}
schneidz@lq> a.out
float s = 4.180000 :: int i (s x 100) = 417

jmgibson1981 · 07-02-2024, 01:52 PM

You are trying to toss a float to an int. Try this

Code:

#include <stdio.h>

int main()
{
    float a = 0.0;
    float s = 4.18;

    a = s * 100;

    printf("float s = %.2f :: float a ( s * 100) = %.0f\n", s, a);
}

This will output the value as a float without any decimal places. It's lost in the cast. Why is above my pay grade. This outputs the (assumed) expected data.

Code:

#include <stdio.h>

int main()
{
    float a = 4.18;

    printf("float a (%.2f * 100) = %.2f\n", a, a * 100);
}

For the memory conscious. No reason to allocate a variable, small as it may be if you can avoid it I'd think. yes I'm talking out of my ass.

schneidz · 07-02-2024, 02:03 PM

Quote:

Originally Posted by jmgibson1981

You are trying to toss a float to an int. Try this

Code:

#include <stdio.h>

int main()
{
    float a = 0.0;
    float s = 4.18;

    a = s * 100;

    printf("float s = %.2f :: float a ( s * 100) = %.0f\n", s, a);
}

This will output the value as a float without any decimal places. It's lost in the cast. Why is above my pay grade. This outputs the (assumed) expected data.

thanks but,...
my real code was comparing sprintf(str, "%4.2f", s) strings but some records were still off a few pennys so my new plan is to multiply those columns by 100.

i see a few records where the multiplication is obviously wrong (e.g.: 4.18) so i am now reaching for a better strategy ?
_____

basically my question is how to total up a few thousand dollar amounts from the 4th column of a file and compare the cumulative amount to 75431.31.
if they are equal, then do nothing.
if they are different, then print out: "mismatch: %4.2f" %4.2f".
i keep getting errors like:

Code:

col4sum (116448.27) does not match total (116448.29)
col4sum (81986.13) does not match total (81986.12)

schneidz · 07-02-2024, 02:35 PM

i changed this line and the outputs are more sane now for the exceptionally large groupings:

Code:

schneidz@lq diff era-execute-2024-07-01.c era-execute.c
85c85
<                 sprintf(col4sum, "%4.2f",strtof(col4sum, NULL) + strtof(col4, NULL));
---
>                 sprintf(col4sum, "%4.2f",strtod(col4sum, NULL) + strtod(col4, NULL));

astrogeek · 07-02-2024, 02:45 PM

jmgibson1981 is correct, you cannot toss a float into an integer as in the example code without loss! The compiler will implicitly round and truncate for you, but you always lose "something".

But in general not all numbers can be exactly represented as a float anyway. Try using a double instead in your example and you will likely get what you are after - in this specfic case, but not all cases because not all numbers can be represented as a double either! Next up would be long double which pushes the limit much further to the right* (but it is still there!).

That said, for working with monetary values, i.e. two decimal places, doubles should be sufficient. Multiplying by 100 to get an intermediate result only introduces another potential rounding error.

For absolute exact numeric results look into arbitrary precision and integer math.

*(Further to the right in the representation, i.e. precision, not same as the number of decimal places you can work with, so as to not mislead!)

jmgibson1981 · 07-02-2024, 02:50 PM

Quote:

thanks but,...
my real code was comparing sprintf(str, "%4.2f", s) strings but some records were still off a few pennys so my new plan is to multiply those columns by 100.

Doubles are the better choice but if you want an answer to that, which is a bit of a different thing then you need to post the actual code in question. Can only reply to what we see.

NevemTeve · 07-02-2024, 03:40 PM

As it has been already said, floating point calculations are inaccurate by design; an option is storing cents (pennies) in integer variables. In a 64-bit 'long' variable you can store up to 90000 billion euros this way (9*10^16)

ntubski · 07-02-2024, 06:19 PM

For reference: https://floating-point-gui.de/

Quote:

What Every Programmer Should Know About Floating-Point Arithmetic
or
Why don’t my numbers add up?