Discussion:
[Firebird-docs] LangRef 2.5beta1 - a few suggestions /2
Helen Borrie
2016-03-22 08:58:00 UTC
Permalink
p.39 Number constants
For hexadecimal notation, isn't there something
about the sign that deserves mention here?
The example uses 0X08000000 - the first 0 after the X does serve some purpose.
Aage, do you know about that "something"? If yes, would you write
about it?
----------------------------------------
p.40-41
Table 4.4. Comparison Operator Precedence
"This group also includes comparison predicates
BETWEEN, LIKE, CONTAINING, SIMILAR TO and others."
Could something be said about the precedence of these?
Is there something to be said about it? If you know of a precedence
for these predicates, would you write it up? I have not heard of it.
----------------------------------------
A CONTAINING search is not case-sensitive.
Maybe a comment/warning on accent-sensitivity?
I think you might be the first person involved with this text who has
day-to-day experience with data in a language with accented
characters. What is there to say?
----------------------------------------
I've addressed these points to Aage because he raised them. But
anyone who can answer, please chip in!

Helen
Paul Vinkenoog
2016-03-22 11:25:37 UTC
Permalink
Hi all,
Post by Helen Borrie
p.39 Number constants
For hexadecimal notation, isn't there something
about the sign that deserves mention here?
The example uses 0X08000000 - the first 0 after the X does serve some purpose.
Aage, do you know about that "something"? If yes, would you write
about it?
I think he's referring to this:

http://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/langrefupd25-hexnumerals.html, especially the information under 'Value ranges'.

The line under Number Constants (in the LangRef beta):

"For BIGINT numbers, hexadecimal notation is supported by Firebird 2.5 and higher versions, e.g., 0X080000000 as the hex representation of decimal 2147483648."

should be:

"Hexadecimal notation is supported by Firebird 2.5 and higher versions. Numbers with 1-8 hex digits (e.g. 0x325708) are parsed as INTEGER values, numbers with 9-16 hex digits (e.g. 0x198723457237) as BIGINT."

More explanation about the value ranges and some pitfalls (see link above) can be given in Data Types and Subtypes :: Integer Data Types, before the start of the subsections.

Also (I should have caught this during reviewing), in Data Types and Subtypes :: Integer Data Types :: INTEGER, there should be a similar sentence as under BIGINT, explaining that you can pass INTEGERs in hex notation.

As for SMALLINT: Strictly speaking, you can't write a SMALLINT in hex notation, because even 0x1 is parsed as an INTEGER. But you can supply any value between 0 and 32767 in hex notation (0x0000 - 0x7FFF) wherever a SMALLINT is required and it will be converted automatically.

You can also pass negative smallint values, but that's trickier: you have to write them as 0xFFFF8000 (negative INTEGER -32768) through 0xFFFFFFFF (negative INTEGER -1). In a "true SMALLINT" hex notation, this would be 0x8000 - 0xFFFF.

Cheers,
Paul
Helen Borrie
2016-03-22 20:33:32 UTC
Permalink
Hello Paul,
Post by Paul Vinkenoog
Hi all,
Post by Helen Borrie
p.39 Number constants
For hexadecimal notation, isn't there something
about the sign that deserves mention here?
The example uses 0X08000000 - the first 0 after the X does serve some purpose.
Aage, do you know about that "something"? If yes, would you write
about it?
http://www.firebirdsql.org/file/documentation/reference_manuals/reference_material/html/langrefupd25-hexnumerals.html,
especially the information under 'Value ranges'.
"For BIGINT numbers, hexadecimal notation is supported by
Firebird 2.5 and higher versions, e.g., 0X080000000 as the hex
representation of decimal 2147483648."
"Hexadecimal notation is supported by Firebird 2.5 and higher
versions. Numbers with 1-8 hex digits (e.g. 0x325708) are parsed as
INTEGER values, numbers with 9-16 hex digits (e.g. 0x198723457237) as BIGINT."
More explanation about the value ranges and some pitfalls (see link
above) can be given in Data Types and Subtypes :: Integer Data
Types, before the start of the subsections.
Also (I should have caught this during reviewing),
Actually, one reason you didn't catch it at that time is because there
was nothing there about hexadecimal - it came in a later build and I
just took what was in the release notes. At that time I wasn't fully
aware of just how much of the LangUpdate25 stuff was missing.

Another thing we seem to have missed by the same method (!) was binary
strings in hex format.

Unless you have feelings against it, I should just pick up the
relevant source from LangUpdate25, slot it into the appropriate
places and cross-ref where needed.


Helen
Paul Vinkenoog
2016-03-22 23:51:04 UTC
Permalink
Hi Helen,
Post by Helen Borrie
Another thing we seem to have missed by the same method (!) was binary
strings in hex format.
Unless you have feelings against it, I should just pick up the
relevant source from LangUpdate25, slot it into the appropriate
places and cross-ref where needed.
Yes, please use whatever you can use.

The hex numeral stuff is under langrefupd25-hexnumerals and (BIGINT-specific) langrefupd25-bigint; the 'binary' strings are at langrefupd25-hexbinstrings.


Cheers,
Paul
Paul Vinkenoog
2016-03-22 12:03:55 UTC
Permalink
Hi Helen,
Post by Helen Borrie
A CONTAINING search is not case-sensitive.
Maybe a comment/warning on accent-sensitivity?
I think you might be the first person involved with this text who has
day-to-day experience with data in a language with accented
characters. What is there to say?
Two short tests using iso8859_1 and utf8 reveal that CONTAINING is accent-sensitive, i.e.

'ABCDEFG' containing 'DÉF'

is false, *unless* an accent-insensitive collation is used.

I assume it's the same with other character sets.


Cheers,
Paul
Aage Johansen
2016-03-24 22:01:40 UTC
Permalink
First, thanks to Paul for checking my suggestions.
Actually, I may have misremembered: I thought there might be pitfalls
regarding the sign of the result.

As for BETWEEN and the others: maybe precedence is totally irrelevant
for "comparison predicates". I just mentioned it since "comparison
operators" have defined precedence.
--
Aage J.
ps
I've spent most of Easter in hospital, and haven't really been keen on
doing testing. Sorry about that.
Post by Helen Borrie
p.39 Number constants
For hexadecimal notation, isn't there something
about the sign that deserves mention here?
The example uses 0X08000000 - the first 0 after the X does serve some purpose.
Aage, do you know about that "something"? If yes, would you write
about it?
----------------------------------------
p.40-41
Table 4.4. Comparison Operator Precedence
"This group also includes comparison predicates
BETWEEN, LIKE, CONTAINING, SIMILAR TO and others."
Could something be said about the precedence of these?
Is there something to be said about it? If you know of a precedence
for these predicates, would you write it up? I have not heard of it.
----------------------------------------
A CONTAINING search is not case-sensitive.
Maybe a comment/warning on accent-sensitivity?
I think you might be the first person involved with this text who has
day-to-day experience with data in a language with accented
characters. What is there to say?
----------------------------------------
I've addressed these points to Aage because he raised them. But
anyone who can answer, please chip in!
Helen
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
Paul Vinkenoog
2016-03-28 13:52:02 UTC
Permalink
Post by Aage Johansen
First, thanks to Paul for checking my suggestions.
Actually, I may have misremembered: I thought there might be pitfalls
regarding the sign of the result.
There are. Or rather, there is one: 0x80000000 - 0xFFFFFFFF map to negative INTEGER values, whereas 0x080000000 - 0x0FFFFFFFF map to positive BIGINTs.

But I see Helen has taken care of that in her latest commit.
Post by Aage Johansen
As for BETWEEN and the others: maybe precedence is totally irrelevant
for "comparison predicates". I just mentioned it since "comparison
operators" have defined precedence.
According to IBPhoenix's Using Firebird and Helen's Firebird Book, BETWEEN...AND, LIKE, CONTAINING and STARTING [WITH] all have precedence 9 (lowest) among the comparison operators. I assume that the same is true for SIMILAR TO.
Post by Aage Johansen
I've spent most of Easter in hospital, and haven't really been keen on
doing testing. Sorry about that.
Hope you're doing alright now!


Cheers,
Paul Vinkenoog

Loading...