Are numbers stored as binary ?

[Jean-Marc Vanel]

Hi all

I could not find the answer in the FAQ, nor by googling.
https://jena.apache.org/documentation/tdb/faqs.html

The advantages of numbers stored as binary versus strings are:

- less storage
- less CPU in conversion of string => number when using API
- more efficient SPARQL queries involving numbers computations

--
Jean-Marc Vanel
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
[phone]
Twitter: @jmvanel , @jmvanel_fr ; chat: irc://irc.freenode.net#eulergui

[Andy Seaborne]

Post by Jean-Marc Vanel
Hi all
I could not find the answer in the FAQ, nor by googling.
https://jena.apache.org/documentation/tdb/faqs.html

yes and no.

They are stored in the NodeId if possible.

See class NodeId.

In TDB as released there are 56 bits of space for holding: decimals,
integers and derived types, dateTime, dates, boolean).

If the number does not fit, it is stored long form.

Post by Jean-Marc Vanel
- less storage
- less CPU in conversion of string => number when using API
- more efficient SPARQL queries involving numbers computations

A negative is that exact representation is lost

"+1" and "1" and "0001"

"1"^^xsd:integer and "1"^^xsd:int

Andy

Post by Jean-Marc Vanel
--
Jean-Marc Vanel
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
[phone]

[james anderson]

good morning;

Post by Andy Seaborne

Post by Jean-Marc Vanel
[
]
- less storage
- less CPU in conversion of string => number when using API
- more efficient SPARQL queries involving numbers computations

A negative is that exact representation is lost
"+1" and "1" and "0001"
"1"^^xsd:integer and "1"^^xsd:int

have there been applications where this mattered, where it was eventually decided that it was necessary to entrain some distinction in the encoding and not better to account for the respective semantics explicitly in the model?

best regards, from berlin,
---
james anderson | ***@dydra.com | http://dydra.com

[Andy Seaborne]

Post by james anderson
good morning;

Post by Andy Seaborne

[…]
- less storage - less CPU in conversion of string => number when
using API - more efficient SPARQL queries involving numbers
computations

A negative is that exact representation is lost
"+1" and "1" and "0001"
"1"^^xsd:integer and "1"^^xsd:int

have there been applications where this mattered, where it was
eventually decided that it was necessary to entrain some distinction
in the encoding and not better to account for the respective
semantics explicitly in the model?

Some. Questions comes up on users@ every so often - not frequently.

A user expectation is that read-write of a model does not change the
model but here it does in the detail. So detailed data checking or
ETL-ish apps can be sensitive to this.

And you can see it in SPARQL with sameTerm.

For TDB2, I am thinking of extending it to xsd:doubles (64 bits needed)
which would also extend the range of handled decimals.

Andy

Post by james anderson
http://dydra.com