comparison of String with 0 failed

I've got an application that is supposed to track takings of events for a charity I work with.

I totally overlooked the fact that the takings would be floats not integers and I'm now fixing that. Unfortunately I've run into a problem.

I've already changed the columns in MySQL to floats, and I doubt this is the right way, but I've changed all my views, replacing

@taking.total

with

"%.2f" % @taking.total

Now the problem is that when the value of some departments are 0, I get the following error:

comparison of String with 0 failed

How should I be displaying these floats with the specified format? Is there a better way to do what I want?

Grateful for any insights into this.

Thanks and happy holidays

Matt

What are "takings"?? If you're referring to money, you shouldn't be using floats either -- see the doc for BigDecimal.

You might also be interested in the "money" gem.

FWIW,

Hassan Schroeder wrote:

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 :stuck_out_tongue:

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.

[1]http://www.postal-code.com/binarycode/rails-bar-graph-helper-docs/

Thanks

Matt

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. :slight_smile:

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.

HTH, and good luck!

Hassan Schroeder wrote:

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. :slight_smile:

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.

Thanks

Matt

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. :slight_smile: Glad you found a fix/workaround.

Happy holidays!

Hassan Schroeder wrote:

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 :slight_smile:

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. :slight_smile: Glad you found a fix/workaround.

Haha, well it'll do until the next release :slight_smile:

Happy holidays!

You too

Matt

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.

Harry Bailey wrote:

Nope, MySQL has a decimal data type.

Excellent, I'll have a play :slight_smile:

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 :slight_smile:

Matt