On 5/13/2013 16:36, Keith Christian wrote:
gcc -o libtclsqlite3.so -shared tea/generic/tclsqlite3.c -lpthread -ldl
-ltcl
Don't build it that way. It appears that the TEA build system sees
Cygwin and thinks "oh, this is Windows, so it must be VC++ or MinGW".
That prevents it from linking to
I have the latest version of Cygwin installed (CYGWIN_NT-6.1-WOW64
1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin) and the latest autoconf
archive (sqlite-autoconf-3071602.tar.gz) because it had the required
tclsqlite3.c file in order to build the libtclsqlite3.so shared object.
I ran the
On May 12, 2013 11:36 PM, "James K. Lowden"
wrote:
I'd add also that syntactically the key need is to distinguish "use
floating point arithmetic" from "use integer arithmetic" where no other
type information is available, specifically in numeric constant literals.
On May 13, 2013, at 6:12 PM, Simon Slavin wrote:
> I should have asked you for (1,2,20) as well and we could see whether it
> outputs '10' or '10.0'. But yes, it would appear that in Oracle, NUMERIC
> means FLOAT.
Nah. Plus there is no such type as 'NUMERIC' per se in
Понедельник, 13 мая 2013, 17:03 +01:00 от Simon Davies
:
>On 13 May 2013 16:52, Simon Slavin < slav...@bigfraud.org > wrote:
>>
>> On 13 May 2013, at 3:54pm, Григорий Григоренко < grigore...@mail.ru > wrote:
>>
>>> sample database is:
>>>
>>> PRAGMA FOREIGN_KEYS=1;
May just be showing best representation
main()
{
float a=1,b=2,c=20;
printf("%g\n",a/b*c);
}
Answer: 10
For c=21
Answer: 10.5
SQL> insert into numtypes values(1,2,20);
1 row created.
SQL> select A/B*C from numtypes;
A/B*C
--
12.5
13.5
11.5
Actually, to be more accurate, the internal storage may be far from a float
(as in IEEE double) but a divide on an integer-looking value will certainly
be done with floating point math.
On Mon, May 13, 2013 at 6:13 PM, Paul van Helden wrote:
>
> I should have asked you for
> I should have asked you for (1,2,20) as well and we could see whether it
> outputs '10' or '10.0'. But yes, it would appear that in Oracle, NUMERIC
> means FLOAT.
>
> Of course it does! All the others too.
___
sqlite-users mailing list
On 13 May 2013, at 5:08pm, Michael Black wrote:
> Would appear it's not doing any casting to promote values but just promoting
> everything to float.
I should have asked you for (1,2,20) as well and we could see whether it
outputs '10' or '10.0'. But yes, it would appear
Added that...
Would appear it's not doing any casting to promote values but just promoting
everything to float.
SQL> insert into numtypes values(1,2,21);
1 row created.
SQL> select A/B*C from numtypes;
A/B*C
--
12.5
13.5
11.5
10.5
-Original Message-
On 13 May 2013 16:52, Simon Slavin wrote:
>
> On 13 May 2013, at 3:54pm, Григорий Григоренко wrote:
>
>> sample database is:
>>
>> PRAGMA FOREIGN_KEYS=1;
>> CREATE TABLE cat(id INTEGER PRIMARY KEY, name);
>> INSERT INTO cat VALUES (1, 'Alice');
>> CREATE
On 13 May 2013, at 4:57pm, Michael Black wrote:
> Oracle gives the right answer too for example(contrary to what somebody said
> earlier).
>
> create table numtypes (A NUMERIC, B NUMERIC, C NUMERIC);
> insert into numtypes values (1, 2, 25.23);
> insert into numtypes
Seems to me the SQL standard makes no distinction between columns and
literals does it?
Why should literals be ignored?
Oracle gives the right answer too for example(contrary to what somebody said
earlier).
create table numtypes (A NUMERIC, B NUMERIC, C NUMERIC);
insert into numtypes values (1,
On 13 May 2013, at 3:54pm, Григорий Григоренко wrote:
> sample database is:
>
> PRAGMA FOREIGN_KEYS=1;
> CREATE TABLE cat(id INTEGER PRIMARY KEY, name);
> INSERT INTO cat VALUES (1, 'Alice');
> CREATE TABLE owner(pet INTEGER REFERENCES cat(id));
> INSERT INTO owner
Hi,
sample database is:
PRAGMA FOREIGN_KEYS=1;
CREATE TABLE cat(id INTEGER PRIMARY KEY, name);
INSERT INTO cat VALUES (1, 'Alice');
CREATE TABLE owner(pet INTEGER REFERENCES cat(id));
INSERT INTO owner VALUES(1);
This script fails to drop tables with 'foreign key constraint failed':
Tim, Simon & Darren, if you read my whole OP you will see that I've
discovered this: use REAL instead. My point is that the behaviour of a
NUMERIC column is not intuitive and gives mixed results which wouldn't be a
problem if the division operator could be modified. My suggestion cannot be
too
On 2013.05.12 11:42 AM, Simon Slavin wrote:
I think your problem is just that you have columns declared as NUMERIC. You
can have REAL behaviour if you want: just declare your columns as REAL instead:
I agree with this. In principle, the behavior of addition should be tied to the
data type
17 matches
Mail list logo