What happened to the old: Integer arithmetic produces integer results rule? I thought that was either a "Standard" or at least a very old artifact. Is it not how most Language math functions work?
I like the Pragma idea on this one. > -----Original Message----- > From: Joe Wilson [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 01, 2005 9:10 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2 > > > Although all my Sqlite3 databases depend on integer division > truncation > and would break with your proposed change I agree that 5/2 > should equal > 2.5 in order to be more consistant with other databases. I > can migrate > my databases to use round(). But might it be possible to create a > backwards compatibilty pragma to preserve the old integer division > truncation behavior? Or perhaps a compile-time option? > > How do intend to treat 5/2 if passed to an Sqlite function expecting > an integer argument? An error? 2? 3? I would vote that it would be > treated as 2 in such a case. > > --- [EMAIL PROTECTED] wrote: > > > I am proposing to make the changes outlined below in SQLite > > version 3.3.0 and I am wondering if these changes will cause > > any severe hardship. > > > > Two changes working together: > > > > (1) Floating point values are *always* converted into > > integers if it is possible to do so without loss > > of information. > > > > (2) Division of two integers returns a floating point > > value if necessary to preserve the fractional part > > of the result. > > > > The effect of change (1) is to combine the integer affinity > > and the numeric affinity column types into a single type. > > The new type is called numeric affinity, but it works like > > integer affinity. Change (2) resolves Ralf Junker's > > division paradox. > > > > The only code that I can think of that this change might > > break is cases where the user is depending on the division > > of two integers returning an integer result. Such code > > will need to be modified to use the "round()" function > > to obtain the same result. I am thinking that such code > > should be very uncommon and that this change will have > > minimal impact. Nevertheless, the impact is non-zero so > > I will increment the minor version number as part of this > > change. > > > > If you can think of any other adverse impact that this > > change might have, please let me know. > > -- > > D. Richard Hipp <[EMAIL PROTECTED]> > > > > > > > > > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com
