On 2016-03-13 23:14, jungle Boogie wrote:
> Hi Keith,
> On 13 March 2016 at 13:31, Keith Medcalf wrote:
>> On Sunday, 13 March, 2016 13:36 -07:00, jungle Boogie > gmail.com> wrote:
>>> Here it is in decimal: (select code from sidemeters)
>>> "0"
>>> "1"
>>> "2"
>>> "5"
>>> "6"
>>> "7"
>>> "28"
>>>
Hi Keith,
On 13 March 2016 at 13:31, Keith Medcalf wrote:
> On Sunday, 13 March, 2016 13:36 -07:00, jungle Boogie gmail.com> wrote:
>> Here it is in decimal: (select code from sidemeters)
>> "0"
>> "1"
>> "2"
>> "5"
>> "6"
>> "7"
>> "28"
>> "29"
>> "30"
>> "31"
>
> Assuming that your quotes mean
On Sunday, 13 March, 2016 13:36 -07:00, jungle Boogie wrote:
> On 12 March 2016 at 22:07, J Decker wrote:
> > maybe ?
> > https://www.sqlite.org/lang_corefunc.html
> > hex(X)The hex() function interprets its argument as a BLOB and returns
> > a string which is the upper-case hexadecimal render
On 12 March 2016 at 22:07, J Decker wrote:
> maybe ?
> https://www.sqlite.org/lang_corefunc.html
>
> hex(X)The hex() function interprets its argument as a BLOB and returns
> a string which is the upper-case hexadecimal rendering of the content
> of that blob.
That's what I first tried but not wor
Hello,
According to ``lang_expr.html#hexint'':
``...0x8000 means the same as -9223372036854775808.
Hexadecimal integer literals are interpreted as 64-bit two's-complement
integers...''.
Not necessary:
``SELECT - -9223372036854775808;'' => 9.22337203685478e+18. Ok.
``SELECT -0x80
maybe ?
https://www.sqlite.org/lang_corefunc.html
hex(X)The hex() function interprets its argument as a BLOB and returns
a string which is the upper-case hexadecimal rendering of the content
of that blob.
On Sat, Mar 12, 2016 at 12:18 PM, jungle Boogie
wrote:
> Hello All,
>
> I'm curious to kno
Hello All,
I'm curious to know if there's a better way to run a query and convert
the results to hexadecimal.
This is what I have so far:
SELECT printf("%x %d",code,code), printf("%x", denom) FROM sidemeters
order by denom
The data is already in decimal so I don't necessarily need to include
t
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 Sch
Hi,
Von: Scott Robison
> On Wed, Jul 23, 2014 at 9:46 PM, J Decker 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
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
On Wed, Jul 23, 2014 at 9:46 PM, J Decker 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 having to
> add e
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?
_
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.
P
On Wed, 23 Jul 2014 07:07:25 -0400
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 current SQLite implementation (on the "hex-literal" branch) works
> by converting hex liter
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' or
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 [±$0,026930006220831
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 sign
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
-
On
On 23 Jul 2014 at 12:07, Richard Hipp 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 and OR oper
>
> > 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 bitma
On Wed, Jul 23, 2014 at 10:22 AM, Doug Currie 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 (a) t
> 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
On Wed, Jul 23, 2014 at 9:59 AM, Doug Currie 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 at all? You
> 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
Hi,
Von: Im Auftrag von Dominique Devienne
> On Wed, Jul 23, 2014 at 1:07 PM, Richard Hipp 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 cont
On Wed, Jul 23, 2014 at 2:15 PM, Simon Slavin 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 ide
On 23 Jul 2014, at 12:07pm, Richard Hipp 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 identity (y ==
> (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 exist
On Wed, Jul 23, 2014 at 1:07 PM, Richard Hipp 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 certainly overflo
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 bit
On Wed, Jul 23, 2014 at 1:07 PM, Richard Hipp 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
_
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
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 w
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
On Mon, 2007-01-29 at 19:26 -0300, Brodie Thiesfield wrote:
> Does sqlite support numeric literals in hexadecimal?
> e.g.INSERT INTO table(mask) VALUES (0x);
I don't think so.
> Additionally, is there a constant like MAX_INTEGER defined which I can
> use as the maximum value that an INTEGER f
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 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
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 [EMA
38 matches
Mail list logo
