On Sun, May 12, 2013 at 1:54 PM, Michael Black <mdblac...@yahoo.com> wrote:
> PRAGMA INTEGER_DIVISION would probably not have saved you this bug as you > would not have known to turn it on (default would have to be OFF for > backwards compatibility). I will use it on every connection I make in future to avoid future pain. (I have a SQLite management system where my clients can create their own tables and enter their own SQL for custom reports) On Sun, May 12, 2013 at 2:35 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > I think it's endemic to computers, the same as the difficulty with > counting in units of 0.1 until you get 1. > > On Sun, May 12, 2013 at 2:59 PM, Yan Seiner <y...@seiner.com> wrote: > If you want floats, you have to specify floats. If you want integers, you > have to specify integers. The compiler has no way to know which you want. > > Just get in the habit of always adding a .0 if you want float constants. > > I can live with SELECT 1/2 vs SELECT 1.0/2. The problem is that there is no way to specify a float when you insert into a NUMERIC. 1.0 turns into an integer. Then you do a division on all rows with an SQL select and you get mixed results because some rows have floats and some rows have integers. In C, 1/2=0. In Pascal 1/2=0.5. Oracle/MSSQL/others act like C, MySQL acts like Pascal. This is not my main issue. Consistency throughout a table, is. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
