Re: [sqlite] What does "The use of the amalgamation is recommended for all applications." mean, precisely?

Hi, > I approve of your translation. That interpretation concerns the relative merits of using the separate sources vs the amalgamation, if I understand correctly. Barring special circumstances, the use of the amalgamation is the preferred way; that is understood. What I was wondering is

Re: [sqlite] What does "The use of the amalgamation is recommended for all applications." mean, precisely?

> However, the OP has indicated little that would allow us to guess whether > his project should follow the norm or not. I think my question is independent of my particular project; in fact, I am not working on an SQLite project at the moment. The reason I asked this question is that I have a

Re: [sqlite] What does "The use of the amalgamation is recommended for all applications." mean, precisely?

> Why risk ending up with an unexpected (possibly old) version > by linking at runtime just to save users less than 300K of disk > space? But that's an argument against shared linking in general. I am just curious what idea this particular statement on this particular help-page (specific to

Re: [sqlite] What does "The use of the amalgamation is recommended for all applications." mean, precisely?

> Yes.  SQLite is so small there's really no reason to make a separate library > of it. Well, my Linux distribution may provide a "libsqlite3-dev" package, which makes linking to a recent version of sqlite as simple as adding LDLIBS=-lsqlite3 to the Makefile. By going that path you ensure that

[sqlite] What does "The use of the amalgamation is recommended for all applications." mean, precisely?

Dear all, On the support page http://www.sqlite.org/howtocompile.html, it says: "The use of the amalgamation is recommended for all applications." Is this a general recommendation, to use the amalgamated source file as the preferred way of including SQLite functionality in one's

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

Hi Jay >  No, this is basic SQL order of operations. You are right, that first approach I tried was definitely a brainfart. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

> Please someone show me what is the correct value of this avg() in practice. There are a number of answers to this. To the level of precision that you specified, all answer are completely fine; the error is, in all cases, very small relative to the variance of your input data. It is an

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

Hi Jay, > One should never assume a database uses IEEE 754, so one should never > assume it uses similar semantics. One should not assume it unless it is documented, of course. Postgres, for example, half-heartedly embraces IEEE-754 'on platforms that use it' (see section 8.1.3 of its manual).

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

On Jun 6, 2011, at 21:55, Jean-Christophe Deschamps wrote: > You have a DOUBLE column where you need to store NaN? Go ahead and > store 'NaN' in offending rows. This cannot be done. They will be turned into NULL. Sidney ___ sqlite-users mailing

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

>> > You have a DOUBLE column where you need to store NaN? ?Go ahead and >> > store 'NaN' in offending rows. >> >> You mean, as a string? > >  No, by binding the raw value using the C interfaces as any >  respectable program would do. But then I'd lose the ability to actually use those values in

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

> Given that there are > many, many SQLite3 applications, it is really not possible to say, > with a straight face anyways, that no applications would break. That is true. I would certainly not advocate changing the default behavior. However the 'once we make a mistake, we can't fix it' idea

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

On Mon, Jun 6, 2011 at 9:55 PM, Jean-Christophe Deschamps wrote: > You have a DOUBLE column where you need to store NaN?  Go ahead and > store 'NaN' in offending rows. You mean, as a string? That's rather a dirty hack. Also, it doesn't work as it should: sqlite> SELECT 1.0

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

Hi Jay, > One should never assume a database uses IEEE 754, so one should never > assume it uses similar semantics. One should not assume it unless it is documented, of course. Postgres, for example, half-heartedly embraces IEEE-754 'on platforms that use it' (see section 8.1.3 of its manual).

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

> Ah.  In that case, I /would/ argue that this is bad, and that SQLite should > conform to the standard. That is true, although it is rather unfortunate that the standard makes this statement, IMHO. Unfortunately, this doesn't address the point of whether it should be possible to use NaNs as

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

> It'd be OK for NaN to map to NULL, but not for infinity, since there > is a distinction between positive and negative infinity, and that > distinction is valuable. The NaN value in IEEE-754 is also not unique. There is the distinction between signaling and quiet NaNs, and furthermore mantissa

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

Hi Simon, > But you were using a SQL command to make the match. Well, I was using it to demonstrate some behavior I observed, yes. I was not "matching values with NULL". But whatever. > You executed a SELECT command and got an answer from SQL.  That answer does > not mean > "The result of the

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

Hi Simon, > Jay is talking about SQL.  SQL /does/ use NULL for 'unknown'. Well yes, it does, but my entire point is that floating point NaN is quite different from "Unknown". SQLite sort-of unifies NaN and NULL (although this isn't documented). However, this is not an SQL choice -- it is an

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

Hi Simon, > "Null is a special marker used in Structured Query Language (SQL) to indicate > that a data value does not exist in the database." To me, this statement does not apply to "NaN", which is a perfectly fine (albeit unusual) floating point value. > If you compare anything with NULL,

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

Hi Jay, >  However, it is worth remembering that IEEE 754 is really about building >  processors, not about end-user interaction.  While it is a rigid, >  formal specification of a numeric environment, at its heart it is >  about mechanics, not about consistent mathematical systems built on >  

Re: [sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

> Note that according to SQL semantics, 'NULL' means 'I don't know'. I am not quite sure what you are saying. I am pretty sure that NULL is not defined so informally ... :) > So every value of all types matches with it. I don't understand what "matches with" means in this context, sorry.

[sqlite] Handling of IEEE-754 nan and +/-inf in SQLite?

Hi all, Is the way in which SQLite handlesNaN and Infinity values as defined by IEEE-754 documented somewhere? I would also be interested to find a discussion of the rationale behind the design decisions. After some experimenting, it appears that ... * SELECT 1.0 / 0.0 yields NULL (where I