What are "takings"?? If you're referring to money, you shouldn't be
using floats either -- see the doc for BigDecimal.
Thanks for the reply,
I am dealing with money, and I do know there are problems with calculations and float accuracy. I have taken a quick look at the money gem and BigDecimal, but I don't see how they will do the job I want.
I think I'm in the holiday spirit too much to do math, but I've said I'll have this sorted
I've done some testing and the error doesn't appear when just outputting the value in a view. I'm using the BarGraph helper[1], and it's only when I'm setting the values for the graph that I get the error.
I am dealing with money, and I do know there are problems with
calculations and float accuracy. I have taken a quick look at the money
gem and BigDecimal, but I don't see how they will do the job I want.
?? Not sure what that means, but there's no question you should
use BigDecimal to represent a decimal value like money. Or to put
it another way, there's no conceptual reason to use a Float for this.
I've done some testing and the error doesn't appear when just outputting
the value in a view. I'm using the BarGraph helper[1], and it's only
when I'm setting the values for the graph that I get the error.
Ah, OK. That helper is apparently using the supplied input values as
numbers to generate the graph. Trying to turn a value into a String at
that point is definitely going to cause the failure you're seeing.
If you want a decimal number like "100.00" to /display/ in the view, I
think you'll need to change the helper. Bummer that there don't seem
to be any tests for it.
I am dealing with money, and I do know there are problems with
calculations and float accuracy. I have taken a quick look at the money
gem and BigDecimal, but I don't see how they will do the job I want.
?? Not sure what that means, but there's no question you should
use BigDecimal to represent a decimal value like money. Or to put
it another way, there's no conceptual reason to use a Float for this.
I am just unsure about using BigDecimal. I can see it is better to use than a float, but how would that work with the database? I can create float columns but not BigDecimal i believe. Would I need to store the values as floats in MySQL but then convert to BigDecimal later?
I've done some testing and the error doesn't appear when just outputting
the value in a view. I'm using the BarGraph helper[1], and it's only
when I'm setting the values for the graph that I get the error.
Ah, OK. That helper is apparently using the supplied input values as
numbers to generate the graph. Trying to turn a value into a String at
that point is definitely going to cause the failure you're seeing.
If you want a decimal number like "100.00" to /display/ in the view, I
think you'll need to change the helper. Bummer that there don't seem
to be any tests for it.
Thanks, I have hacked around in the helper and have got it to convert the values after they are processed.
HTH, and good luck!
Now, it does what I want, but I will keep looking around BigDecimal.
I am just unsure about using BigDecimal. I can see it is better to use
than a float, but how would that work with the database? I can create
float columns but not BigDecimal i believe. Would I need to store the
values as floats in MySQL but then convert to BigDecimal later?
Nope, MySQL has a decimal data type.
Thanks, I have hacked around in the helper and have got it to convert
the values after they are processed.
Yeah, I was looking at that, but got distracted by present unwrapping.
Glad you found a fix/workaround.
I am just unsure about using BigDecimal. I can see it is better to use
than a float, but how would that work with the database? I can create
float columns but not BigDecimal i believe. Would I need to store the
values as floats in MySQL but then convert to BigDecimal later?
Nope, MySQL has a decimal data type.
Excellent, I'll have a play
Thanks, I have hacked around in the helper and have got it to convert
the values after they are processed.
Yeah, I was looking at that, but got distracted by present unwrapping.
Glad you found a fix/workaround.
You may want to give it extra precision, depending on how you'll be using it.
I have mine at 8,3 to avoid losing an occasional penny during interest calculations, though for some (most?) applications it's better to allow that to happen.
In mine if I have a block of accounts totaling, say, $100,000, it should produce a certain amount of interest. But in calculating each account individually it most likely won't come out to the expected amount unless I can have fractions of pennies.
You may want to give it extra precision, depending on how you'll be using it.
I have mine at 8,3 to avoid losing an occasional penny during interest calculations, though for some (most?) applications it's better to allow that to happen.
In mine if I have a block of accounts totaling, say, $100,000, it should produce a certain amount of interest. But in calculating each account individually it most likely won't come out to the expected amount unless I can have fractions of pennies.
Thanks for the reply, its nice to have some input on the usage.
The application I'm working on is for a very small charity, the numbers rarely get larger than 500 and calculations are very simple (addition for the event totals).
I'm going to put together a test app so I can play with the new type, I'm demoing the production app next week I hope so I'll probably look to implement it late jan, plenty of time to fiddle
