Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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?

Re: [sqlite] Hexadecimal integer literals

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.

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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'

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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 -

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

> > > 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

Re: [sqlite] Hexadecimal integer literals

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. > > > > > >

Re: [sqlite] Hexadecimal integer literals

> 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 > >

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

> 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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

> (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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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

Re: [sqlite] Hexadecimal integer literals

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

[sqlite] Hexadecimal integer literals

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