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

[Anthony T. <an...@co...>]

On Mon, 2003-10-06 at 13:17, Geoff Gerrietts wrote:
> Quoting Anthony Tuininga (an...@co...):
> > The only possibility that I can think of right now is that they incur
> > the overhead of checking if trunc(result) == result and returning an
> > integer as a result. That has two problems with it, though. (1) the
> > performance penalty and (2) the possibility of getting back an integer
> > when you wanted a float
> 
> DCOracle and DCOracle2 both returns a float in this (select count(*))
> case.

Ok. So someone else had the same problem and came up with the same
solution. Good. :-)

> 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?

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

> DCOracle2 seems to use slightly more of the OCI API, but the code is
> nowhere near as clean and comprehensible as the code in cx_Oracle.

Thanks. It would be interesting to note which parts of the OCI API
DCOracle uses that cx_Oracle does not -- mostly out of curiosity but
sometimes interesting enhancements turn up as a result... :-)

> I prefer the DCOracle behavior only because I have coded to it in the
> past. I think the DCOracle behavior makes reasonable sense, but the
> DCOracle2 behavior does, too. Of course, I've already voted... ;)

See the above. Does that make sense to you?

> I don't deal with a lot of large numeric values, but I am a little
> concerned about FP "roundoff" and FP precision errors, and returning
> all values as strings is interesting but incurs more overhead than I'm
> willing to stomach.

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?

> Just hoping to add some points of comparison to the discussion.

Thanks.

> Thanks,
> --G.
-- 
Anthony Tuininga
an...@co...
 
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com