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
25 matches
Mail list logo