[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: return of BigFloat errors

On Tue, Jan 1, 2013 at 7:26 AM, Michael Richardson <..hidden..> wrote:

>>>>> "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> involving
    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
our intentions.

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.

Best Wishes,
Chris Travers