[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: return of BigFloat errors
- Subject: Re: return of BigFloat errors
- From: Chris Travers <..hidden..>
- Date: Tue, 1 Jan 2013 07:39:18 -0800
On Tue, Jan 1, 2013 at 7:26 AM, Michael Richardson <..hidden..>
>>>>> "Chris" == Chris Travers <..hidden..> writes:
Chris> First, my reading of the log (and sorry I haven't been able
Chris> to get to it
Chris> yesterday) is that this is a tax included invoice. I am
Chris> wondering if it is
Chris> really the amount_$i that is undefined or the tax rate.
yes, that's true.
amount_$i was 9, but there wasn't such a thing in the form.
That's because rowcount was 15 for some reason, and blank rows are not
being ignored for some reason.
Chris> table for my testing purposes, that would be helpful. I am
Chris> also not quite
Chris> sure what happens with Math::BigFloat when arithmetic is done
Chris> undefs. In the past they used to be treated as zeros, but it
Chris> is likely
Chris> that the errors we are getting are a result of changing
Chris> behavior there.
Seems to call for a regression test case on Math::BigFloat to assert
Maybe it used to do that, (undef == 0) and now it doesn't?
I believe that is the case. It is only the most recent version which causes this. This means that is_zero errors only affect some of our users.
For better or worse this is a case of a dependency in CPAN changing behavior in a way that has caused problems in our code.