Comparison of String with 0 failed


#1

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


#2

On Thu, Dec 25, 2008 at 9:21 AM, Matt H.
removed_email_address@domain.invalid wrote:

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.

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 S. ------------------------ removed_email_address@domain.invalid


#3

Hassan S. 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


#4

Hassan S. wrote:

On Thu, Dec 25, 2008 at 10:06 AM, Matt H.
removed_email_address@domain.invalid 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?

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


#5

On Thu, Dec 25, 2008 at 12:36 PM, Matt H.
removed_email_address@domain.invalid 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.

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 S. ------------------------ removed_email_address@domain.invalid


#6

Hassan S. wrote:

On Thu, Dec 25, 2008 at 12:36 PM, Matt H.
removed_email_address@domain.invalid 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


#7

On Thu, Dec 25, 2008 at 10:06 AM, Matt H.
removed_email_address@domain.invalid 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’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 S. ------------------------ removed_email_address@domain.invalid


#8

Harry Bailey wrote:

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


#9

On Dec 25, 2008, at 5:02 PM, Matt H. 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.