Re: [SPAM-bayes] Re: [cx-oracle-users] float vs. int

[Geoff G. <ge...@ge...>]

Quoting Anthony Tuininga (an...@co...):
> > For columns with a precision > 9 and a scale 0, DCOracle2 returns a
> > Long by default, without comparing the actual value to sys.maxint.
> > DCOracle compares the actual value and returns a Long only if an Int
> > would overflow.
> 
> Hmm. Python 2.3 will automatically convert to long when the value won't
> fit inside an integer. Python 2.2 and below will not, of course, but
> that could be checked by looking for an OverflowError and doing the
> right conversion otherwise. I think that makes a lot of sense. What do
> you think?

Yes, that goes along with what I think the principle of least surprise
should dictate. The full unification in 2.3 is obviously the best of
all worlds, but until everyone's on 2.3+, getting as close as possible
seems like the "right" thing to do (and it has the advantage of
continuing to be the right thing in 2.3 and beyond).

> > DCOracle does all its data conversion by poking around inside Oracle's
> > data structures, I think. I don't know the OCI API very well but very
> > few OCI calls are actually being made by DCOracle.
> 
> I believe I am making the same ones. I didn't actually look but Oracle
> does provide the scale and precision of numbers and that is what I am
> checking.

The original DCOracle started life as a SWIG wrap of the OCI API. It
was heavily hacked to produce a more-or-less compliant module.

As near I can tell -- which is not too close, because I've spent only
a couple of days spread over a couple of years looking at the
Byzantine beast -- it copies data directly out of the OCI's mapped
memory region and into some Pythonic data structures. Chances are good
to middling that I am missing something key, but doing a grep for
fairly standard calls (like "OCINumber.*") yields hits only in object
files.

DCOracle2 I am even less familiar with. It does use the more regular
calls, though.

> Floating point is always a problem in that regard. Thus the introduction
> of fixed point classes. But they have their own set of problems --
> mostly that they are not intrinsic to a lot of other algorithms. Someone
> earlier posted a link to a fixed point class. I may do something a
> little less functional directly in C or provide a mechanism for
> registering a "fixed point" class for use by cx_Oracle in returning such
> things. Any thoughts on that?

Floating point is pretty standard. Fixed point really isn't, though. I
mean, there's the "standard" module Tim Peters wrote. I think I read
once upon a time that Aahz was looking at tightening that up possibly
for inclusion in the standard library but I honestly haven't followed
it.

I do know that the CORBA IDL mapping to Python includes some kind of
hijinx surrounding fixed point, too. To me, that looks like an
opportunity for an implementation to "go rogue" and not conform to the
standards. Integration with the DB layer seems like another one.

I'm not sure what the /right/ answer is to all the fixed point and
floating point issues. I'm certainly not well-versed in the array of
possible solutions, because to date I've been ducking my head and
gambling that a float will be good enough. But I think any solution's
value will be measured in part by how easy it is to use with other
fixed point / floating point solutions, with "effortless" or
"identical" being the ideal.

I think that's just a wordy way of saying "standards are good." :)

Thanks,
--G.

-- 
Geoff Gerrietts             "Me and my homies, we tag O.D.."
<geoff at gerrietts net>        --Unknown grafitti artist at a party