Hi, Eric,
Von: Eric Rubin-Smith
So far no one has raised the idea of using a big int layer to implement
proper integer arithmetic past 64 bits. The fact that it hasn't been
mentioned makes me worry that it's a blatantly silly idea for SQLite for some
reason -- but I'm tossing it out there
Hi,
Von: Scott Robison
On Wed, Jul 23, 2014 at 9:46 PM, J Decker d3c...@gmail.com wrote:
Seems like adding hex interpreting is just adding code for the sake of
adding code.
Unless the data is coming from some pre written text file, isn't just
just as easy to format an into into
Right, I've seen the 0o prefix syntax, I just figured I was already pushing
my luck with the 0b prefix. Regardless, I wanted to speak against the idea
of true C style octal constants before someone else asked for them. :)
Apologies for top posting, on my phone.
On Jul 24, 2014 2:58 AM, Markus
We are looking into adding hexadecimal integer literals to SQLite. In
other words, we are looking to enhance SQLite to understand 0x1234 as
another way of writing 4660. Hex literals are useful in conjunction with
the bit-wise AND and OR operators ( and |) and in applications that make
use of bit
On Wed, Jul 23, 2014 at 1:07 PM, Richard Hipp d...@sqlite.org wrote:
(6) Do not support hexadecimal integer literals for casts and affinity
coercions. Only support hex literals in the SQL parser, and throw errors
for oversized hex literals in that context.
+1. --DD
Richard Hipp wrote:
Hex literals are useful in conjunction with
the bit-wise AND and OR operators ( and |) and in applications that make
use of bit fields.
The question is what to do with hex literals that are larger than 64 bits.
There are no bit operations on values larger than 64 bits, so
On Wed, Jul 23, 2014 at 1:07 PM, Richard Hipp d...@sqlite.org wrote:
The current SQLite implementation (on the hex-literal branch) works by
converting hex literals of 64 bits or less into a signed 64-bit integer.
Overflow/underflow are unspecified for signed types, and the / ops
could
(6) Do not support hexadecimal integer literals for casts and affinity
coercions. Only support hex literals in the SQL parser, and throw errors
for oversized hex literals in that context.
I vote for (6) as for being the most predictable behaviour that has no
possibility to break any
On 23 Jul 2014, at 12:07pm, Richard Hipp d...@sqlite.org wrote:
(3) Convert hex literals of 63-bits or less into integers and convert
64-bit or larger hex literals into a floating-point approximation.
BLOBs. Anything longer than 64 bits should be BLOBs. Code which compares two
values for
On Wed, Jul 23, 2014 at 2:15 PM, Simon Slavin slav...@bigfraud.org wrote:
(3) Convert hex literals of 63-bits or less into integers and convert
64-bit or larger hex literals into a floating-point approximation.
BLOBs. Anything longer than 64 bits should be BLOBs. Code which compares
two
Hi,
Von: Im Auftrag von Dominique Devienne
On Wed, Jul 23, 2014 at 1:07 PM, Richard Hipp d...@sqlite.org wrote:
(6) Do not support hexadecimal integer literals for casts and affinity
coercions. Only support hex literals in the SQL parser, and throw
errors for oversized hex literals in
There is this range of negative
values smack in the middle of an otherwise uniformly increasing sequence of
positive numbers. That negative range seems discombobulating.
Why are hex literals interpreted as signed at all? You could simply
consider all hex literals as unsigned values. If you
On Wed, Jul 23, 2014 at 9:59 AM, Doug Currie doug.cur...@gmail.com wrote:
There is this range of negative
values smack in the middle of an otherwise uniformly increasing sequence
of
positive numbers. That negative range seems discombobulating.
Why are hex literals interpreted as signed
Why are hex literals interpreted as signed at all? You could simply
consider all hex literals as unsigned values. If you need a negative
value,
prefix it with the - operator, e.g., -0x77.
With this approach (a) there is no discombobulating segment, (b) all 64
bit
bit-masks are
On Wed, Jul 23, 2014 at 10:22 AM, Doug Currie doug.cur...@gmail.com wrote:
Why are hex literals interpreted as signed at all? You could simply
consider all hex literals as unsigned values. If you need a negative
value,
prefix it with the - operator, e.g., -0x77.
With this approach
Here's an analogy: a sequence of decimal digits is unsigned; it only
becomes negative when you put a - in front of it.
Why shouldn't hex work the same way? (to eliminate the discombobulating
segment)
Because then you would not be able to write (in hex) a 64-bit bitmap that
had the
On 23 Jul 2014 at 12:07, Richard Hipp d...@sqlite.org wrote:
We are looking into adding hexadecimal integer literals to SQLite. In
other words, we are looking to enhance SQLite to understand 0x1234 as
another way of writing 4660. Hex literals are useful in conjunction with
the bit-wise AND
I can think of situations where I would want the result to be truncated
to 64 bits.
I can think of situations where I would want SQLite to raise an error.
I cannot imagine wanting a floating point result.
Gerry Snyder
-
Conversion of oversized hex into FP would break easily and reveal
hardly reproductible across many platforms. Being a support for some
languages fora I observe daily how FP inaccuracies is a real-world
problem in simple-looking code.
The only reasonable thing I can foresee is treat hex as
Like some others I vote for solution 6.
In general accepting hexadecimal notation for floating point values exceeding
64 bits is too developer/scientist friendly. Who needs so much precision use
Fortran or another specialized language rather than SQL of any flavor. My €
2E-2
Hello!
Just like the others in this conversation, I also believe that you
must not change the rules how strings are converted to integers by
type affinity, or by type conversions of arithmetic operators. Thus,
you must not add hexadecimal representation to conversions (nor hex
floats or 'inf'
On Wed, 23 Jul 2014 07:07:25 -0400
Richard Hipp d...@sqlite.org wrote:
Hex literals are useful in conjunction with the bit-wise AND and OR
operators ( and |) and in applications that make use of bit fields.
...
The current SQLite implementation (on the hex-literal branch) works
by converting
So far no one has raised the idea of using a big int layer to implement
proper integer arithmetic past 64 bits. The fact that it hasn't been
mentioned makes me worry that it's a blatantly silly idea for SQLite for
some reason -- but I'm tossing it out there on the off chance that it's
useful.
Seems like adding hex interpreting is just adding code for the sake of
adding code.
Unless the data is coming from some pre written text file, isn't just just
as easy to format an into into decimal as it is for hex without having to
add extra characters for the prefix?
On Wed, Jul 23, 2014 at 9:46 PM, J Decker d3c...@gmail.com wrote:
Seems like adding hex interpreting is just adding code for the sake of
adding code.
Unless the data is coming from some pre written text file, isn't just just
as easy to format an into into decimal as it is for hex without
Hello,
I'm trying to use hexadecimal numbers in a where clause and it
seems things aren't quite working as expected. I get unknown token
errors or inequalities don't return the correct answer.
I have one value set:
sqlite SELECT HEX(minMAC) FROM manifests;
00C1
Clay Baenziger [EMAIL PROTECTED] wrote:
Let's try a small number:
sqlite SELECT HEX(minMAC) FROM manifests WHERE minMAC = X'04';
00C1
[Wrong -- x'04' x'00C1']
Blobs are not compared as if they are very large integers, but rather
lexicographically, byte by byte (the way
Does sqlite support numeric literals in hexadecimal?
e.g.INSERT INTO table(mask) VALUES (0x);
Additionally, is there a constant like MAX_INTEGER defined which I can
use as the maximum value that an INTEGER field supports (assuming that
types actually exist)?
Regards,
Brodie
Hi list,
can I insert a hexadecimal value to an integer field? if yes How can
do that?
Thanks,
Lloyd
__
Scanned and protected by Email scanner
-
To unsubscribe, send email to
Hi Lloyd,
On Wed, 25 Oct 2006 20:11:49 +0530, you wrote:
Hi list,
can I insert a hexadecimal value to an integer field?
Yes.
if yes How can do that?
Convert it to an integer in your host language first.
The X'hexstring' syntax is only for BLOBs.
Thanks,
Lloyd
--
( Kees Nuyt
)
30 matches
Mail list logo