[Wellington-pm] numeric types

Richard Hector richard at walnut.gen.nz
Sun Oct 26 23:44:21 PDT 2008

On Mon, 2008-10-27 at 15:26 +1100, Daniel Pittman wrote:

> > However, I'm not sure that's so useful if whenever I transfer between
> > a Perl program and my DB, I'm converting it to a floating point
> > number.
> Perl?  Use an exact numeric type, and do all your math with that.
> Seriously, don't screw around with (inexact) floating point numbers and
> money, because it makes baby accountants cry.

Sure. That's what I'm trying to do.

> Specifically, see bigrat(3perl) for the easy path, or Math::BigRat for
> the library that uses if you want to do it the hard way.[1]

That looks like it might be a nice way to store numbers, but I still
have the issue of how to get them out of the DB and into one of those
without converting to a float along the way.

> > I'm not even clear that that's what will happen; it seems difficult to
> > work out how Perl has actually stored a given value; perhaps DBI
> > returns it as a string, which I can match and stick into a more
> > complex data structure that preserves the components?
> You can use Data::Dumper, or one of the non-bundled methods, to probe
> what data type it is -- but, generally, it is fairly mutable.

This is the core of my question, I think. I've done a few tests, and
Data::Dumper doesn't seem to display scalars any differently based on
their storage, as far as I can see. What are these 'non-bundled methods'
you're talking about?

> I strongly suspect it will return them as a string value, but don't have
> time to test myself.  Perhaps you could, and let us know?
> > How do I know what's happening, and how do I ensure that I'm getting
> > what I want?
> Hard work and enthusiasm.  You can probably derive appropriate black-box
> testing from this: http://speleotrove.com/decimal/decifaq1.html#inexact

Test by doing calculations and seeing what I get? I can see that that
could work, but I suspect conversions could happen in multiple places,
leading to ambiguity of my results.

Besides - I'm sure I've heard of built-in functionality that will tell
me what I've got; I just can't find it ...

Andrew: whether I actually need this is a separate issue, of course ...
but that speleotrove link gives examples of these issues showing up in
funny places.

I'm tempted to just store everything as pairs (numerator and
denominator) of integers. Seems much more precise than what SQL's
numeric type can offer. And if I can't get those numeric numbers in and
out of perl easily, then perhaps less work as well.


More information about the Wellington-pm mailing list