On Wed, Oct 28, 2015 at 9:08 PM, SQLite
wrote:
>
> On 28 Oct 2015, at 7:36pm, General Discussion of SQLite Database
> wrote:
>
>> Has anybody received email from Alexa since the policy change? I have
>> not
>
> Nor me. I reliably got one for every post I made for about a week before the
On 10/28/15, SQLite mailing list
wrote:
>
> This is ridiculous. I know how to handle spam. I can do nothing
> about not knowing who sent these emails.
>
One thing you could do is add a signature line, to tell the rest of us
who you are :-)
--
D. Richard Hipp
drh at sqlite.org
On 2015-10-28 10:34 PM, SQLite mailing list wrote:
> On 10/28/15, SQLite mailing list
> wrote:
>> This is ridiculous. I know how to handle spam. I can do nothing
>> about not knowing who sent these emails.
>>
> One thing you could do is add a signature line, to te
was a minor inconvenience and the solution imposed
is much more of a PITA than she was.
On 28 October 2015 at 20:34, SQLite mailing list
wrote:
> On 10/28/15, SQLite mailing list
> wrote:
>>
>> This is ridiculous. I know how to handle spam. I can do nothing
>> ab
>
> Those binary representations can be converted back into precise decimal
> representations, but those decimal representations will not be the original
> decimal values, because they were translated from decimal strings into
> binary floating-point values and back into decimal strings.
>
>
> Has anybody received email from Alexa since the policy change? I have
> not
I have never received any ... presumably Alexa's MTA (s if more than one) is
blacklisted ...
On 28 Oct 2015, at 10:34pm, SQLite mailing list wrote:
> This explains the deficiency in the SQLite print function, but it doesn't
> have to be that way.
I'm with a previous poster. SQLite is primarily a database system. Its
primary jobs are storage and retrieval. It shouldn't
no longer do.
Kind regards,
Philip Bennefall
On 10/28/2015 11:49 PM, SQLite mailing list wrote:
>
>> Has anybody received email from Alexa since the policy change? I have
>> not
> I have never received any ... presumably Alexa's MTA (s if more than one)
Sorry, I missed out my point:
SQLite version 3.8.10.2 2015-05-20 18:17:19
Enter ".help" for usage hints.
sqlite> CREATE TABLE t(r REAL PRIMARY KEY,t TEXT);
sqlite> INSERT INTO t VALUES (21.0,'twenty one point zero');
sqlite> INSERT INTO t VALUES (9.2+7.9+0+1.0+1.3+1.6, 'calculation');
sqlite>
On Wed, Oct 28, 2015 at 3:52 PM, SQLite mailing list <
sqlite-users at mailinglists.sqlite.org> wrote:
> On 28 Oct 2015, at 10:34pm, SQLite mailing list <
> sqlite-users at mailinglists.sqlite.org> wrote:
> > This explains the deficiency in the SQLite print function,
need to get rid of (something I have already done).
>
> I vote for 3. Alexa was a minor inconvenience and the solution imposed
> is much more of a PITA than she was.
>
>
>
>
> On 28 October 2015 at 20:34, SQLite mailing list
> wrote:
>> On 10/28/15, SQLite mailing list
On 10/28/2015 6:52 PM, SQLite mailing list wrote:
> However, I would support improvement in its floating point calculations,
> including implementing 'slop' in testing for equality. This is not only for
> use when expressions include the equal sign, but also for cases where
> c
At 23:34 28/10/2015, you wrote:
>---
> > Those binary representations can be converted back into precise decimal
> > representations, but those decimal representations will not be the
> original
> > decimal values, because they were translated from decimal strings into
> > binary floating-point
On 28 Oct 2015, at 11:23pm, SQLite mailing list wrote:
> This can't possibly work. "Fuzzy equality" is not transitive (x is close
> enough to y, y is close enough to z, but x is just far enough from z to be
> non-equal), which would break any indexing scheme.
Oh crumbs
On 10/28/2015 7:25 PM, SQLite mailing list wrote:
> On 28 Oct 2015, at 11:23pm, SQLite mailing list mailinglists.sqlite.org> wrote:
>
>> This can't possibly work. "Fuzzy equality" is not transitive (x is close
>> enough to y, y is close enough to z, but x is just
On Wed, Oct 28, 2015 at 6:29 PM, SQLite mailing list <
sqlite-users at mailinglists.sqlite.org> wrote:
> On 10/28/2015 7:25 PM, SQLite mailing list wrote:
>
>> On 28 Oct 2015, at 11:23pm, SQLite mailing list <
>> sqlite-users at mailinglists.sqlite.org> wrote:
On Wed, 28 Oct 2015 17:52:25 + Simon wrote:
> On 28 Oct 2015, at 5:08pm, James K. Lowden
> wrote:
>
> > If we accept what you say, above, then why should
> >
> >> (9.2+7.8+0+3.0+1.3+1.7)
> >
> > in particular present any problem? There's no division. Each value
> > has an exact decimal
On 29 October 2015 at 09:46, SQLite mailing list <
sqlite-users at mailinglists.sqlite.org> wrote:
>
> which I understood to mean, "if you can represent it in decimal, you
> can represent it in binary". I didn't think that was true, but there
> seemed to be concensus t
On 29 Oct 2015, at 2:09am, SQLite mailing list wrote:
> The consensus was the other way: "If you can represent it in binary, you
> can represent it in decimal."
Well that one is actually true. If you can represent any non-recurring
fraction in binary, in decimal it's a non-re
Yeah. Let's not admit defeat to a lone a**hole. My spam filter is bored
anyway -- let's give it something to do.
Eric
Sent from my iPhone
> On Oct 28, 2015, at 19:12, SQLite mailing list mailinglists.sqlite.org> wrote:
>
> I agree. This cure is worse than the disease.
&
On Thu, 29 Oct 2015 10:09:28 +0800
SQLite mailing list wrote:
> The consensus was the other way: "If you can represent it in binary,
> you can represent it in decimal."
Gah, I see now. Thank you for the clarification.
--jkl
On Wed, Oct 28, 2015 at 6:52 PM, General Discussion of SQLite Database <
sqlite-users at mailinglists.sqlite.org> wrote:
> Effective immediately, the sender email address for mailing list posts
> will be elided. All replies must go back to the mailing list itself.
>
Please reconsider. Not
Hi, everyone.
I've been auditing the OpenBSD codebase for calls to ctype functions
with potentially signed chars. This is undefined on some platforms. I
found a number of instances in Sqlite, so I cloned your repo and ran my
script on it.
Here's the relevant CERT entry:
>> (9.2+7.8+0+3.0+1.3+1.7)
>in particular present any problem? There's no division. Each value
>has an exact decimal representation. I'm prepared to assert that any
>permutation of their sums also has an exact decimal representation.
>Therefore they should have an exact binary representation,
24 matches
Mail list logo
