16 May, 2009, Dean wrote in the 41st comment:
Votes: 0
It could have something to do with Zenn also running a SW MUD? Though if that's the case it only validates what you say even more so Kline.
16 May, 2009, Sharmair wrote in the 42nd comment:
Votes: 0
For what it's worth, if you want to use just integer math, you can do something like:
int percent = (share->numowned*100)/corp->numshares;
16 May, 2009, Banner wrote in the 43rd comment:
Votes: 0
I wanted it to display at least one point past the decimal which is why I used the floating point.
17 May, 2009, Sharmair wrote in the 44th comment:
Votes: 0
Ok, a bit more complex:
int mills = (share->numowned*1000)/corp->numshares;
printf("%d.%d", mills/10, mills%10);
17 May, 2009, Banner wrote in the 45th comment:
Votes: 0
Sharmair said:
Ok, a bit more complex:
int mills = (share->numowned*1000)/corp->numshares;
printf("%d.%d", mills/10, mills%10);
Geeze, Sharamair, I'll just stick with the float. :)

float x = share->numowned;
float percent = (x/corp->numshares)*100;


Thanks though!
17 May, 2009, Davion wrote in the 46th comment:
Votes: 0
Banner said:
float x = share->numowned;
float percent = (x/corp->numshares)*100;


If you want to only display X number of decimal places, use a dot followed by a number in a printf statement. Eg

printf("%.2f", percent);


This will always show 2 decimal places (even if the last spot is 0).
20 May, 2009, flumpy wrote in the 47th comment:
Votes: 0
Davion said:
Banner said:
float x = share->numowned;
float percent = (x/corp->numshares)*100;


If you want to only display X number of decimal places, use a dot followed by a number in a printf statement. Eg

printf("%.2f", percent);


This will always show 2 decimal places (even if the last spot is 0).



HOWEVER

Be careful with using floats. Any negative power of ten cannot be adequately represented using floating point arithmetic, and is particularly unsuited for monetary calculations.

For example:
float price = share->price;
float gross = (x/corp->numshares) * price
float net = gross - 1.10 // take off a 1.10 commission perhaps?

printf("%.2f", net); // gives the wrong answer
20 May, 2009, David Haley wrote in the 48th comment:
Votes: 0
I'm not sure which wrong answer you're expecting, maybe you could give a more clear example…

$ cat test.c

#include <stdlib.h>
#include <stdio.h>

int main()
{
float price = 25.5;
float gross = 2 * price;
float net = gross - 1.10; // take off a 1.10 commission perhaps?
printf("%.2f\n", net); // gives the wrong answer

printf("%.2f\n", -1.0);
printf("%.2f\n", -10.0);
printf("%.2f\n", -100.0);
}

$ gcc test.c
$ ./a.out
49.90
-1.00
-10.00
-100.00


All of these are very precisely the correct answer.

I admit to being rather skeptical of your claim. If floating point arithmetic were so particularly unsuited to monetary calculations, I can think of a few companies who, well, wouldn't be using it.
20 May, 2009, flumpy wrote in the 49th comment:
Votes: 0
the IEEE specification for dealing with floating points is ill suited to monetary calculations:

http://en.wikipedia.org/wiki/IEEE_754

specifically:

http://en.wikipedia.org/wiki/Floating_po...

Quote
Accuracy problems

The fact that floating-point numbers cannot faithfully mimic the real numbers, and that floating-point operations cannot faithfully mimic true arithmetic operations, leads to many surprising situations. This is related to the finite precision with which computers generally represent numbers.



But the representable number closest to 0.01 is

0.009999999776482582092285156250 exactly.



including any negative POWER of 10 (0.1, 0.01, 0.001 etc) cannot be represented correctly either.

And at our company we try not to use floating points or doubles to represent money exactly because of this. We use BigDecimal or ints.
20 May, 2009, David Haley wrote in the 50th comment:
Votes: 0
I work at a hedge fund which (obviously, due to the nature of the business) regularly deals with very large quantities of money day in and day out, and we've gotten away with using floating point arithmetic just fine for quite some time now, so… dunno what to tell you.

In fact, I just tried squaring 0.1, and got 0.01, as expected.

So….. you said that it would give the wrong answer, so again, do you have an example?
21 May, 2009, flumpy wrote in the 51st comment:
Votes: 0
David Haley said:
I work at a hedge fund which (obviously, due to the nature of the business) regularly deals with very large quantities of money day in and day out, and we've gotten away with using floating point arithmetic just fine for quite some time now, so… dunno what to tell you.

In fact, I just tried squaring 0.1, and got 0.01, as expected.

So….. you said that it would give the wrong answer, so again, do you have an example?


hah that will teach me to check my examples :D

BTW It is not I that am claiming anything… "Effective Java Programming" ([EJ] Bloch, Joshua . Effective Java™ Programming Language Guide. Addison-Wesley, 2001. ISBN: 0201310058) Item 31 states pretty much what I said. The example from that section shows a (admittedly Java) example of why not to use floats (actually doubles in this example, same difference) for monetary calculations:

// Broken - uses floating point for monetary calculation! 
public static void main(String[] args) {
double funds = 1.00;
int itemsBought = 0;
for (double price = .10; funds >= price; price += .10) {
funds -= price;
itemsBought++;
}
System.out.println(itemsBought + " items bought.");
System.out.println("Change: $" + funds);
}

Quote
If you run the program, you'll find that you can afford three pieces of candy, and you have
$0.3999999999999999 left. This is the wrong answer! The right way to solve this problem is
to use BigDecimal, int, or long for monetary calculations.


Apart from that, and casting floats to ints (thus losing precision), if you are aware of the pitfalls then I guess there are no issues. Its still good practice not to use floats, as it prevents these subtle problems from occuring in your code.

I'm just saying you need to be careful.
40.0/51