Behavior of Literal's Number in Integraal
I have encountered issues multiple times with number literals in Integraal.
In Integraal, the literal 0 (Integer) is distinct from 0L (Long), integers are different from floating-point numbers (0 != 0.0), and 0.0 (Double) is distinct from 0.0f (Float).
This design choice aligns with W3C standards for the Semantic Web, where numbers of different types are treated as distinct. See W3C RDF 1.1 Concepts and Abstract Syntax for more details.
However, this approach is not very practical from the user's perspective, as it requires careful attention to types. Unfortunately, there is no perfect solution to this problem, in my opinion.
Here are three potential options to address this:
- Retain the current behavior but provide thorough documentation to inform users about standard functions for converting literals (
toLong,toInteger,toDouble, etc.) and clarify the default types (Integer for integers and Double for floating-point numbers). - Treat numbers of different types as equal. However, this complicates implementation—for example, when performing joins, it would require testing across all types to find a match.
- Normalize all numbers to a single type while preserving the original type for export purposes.
We need to discuss this issue because users may not understand why their program doesn't work, even though all their rules and queries are correct.
Activity
That's why I have always advocated for the following behaviour of literals:
- we have a syntactic representation "string"^^integraalclassname for a literal
- "somewhere", the integraalclassname is associated to a java class name
- there is a default association hard coded in integraal for standard literal types (aka xsd)
- associations can be overridden, or new integraalclassnames can be created via the json configuration files (same as for functions or views)
- the java class knows how to create objects from strings
- the java class equals method must handle arguments of different types (to be able to test the integer 2 and the float 2.0 as equals)
- there must be some kind of normal form for datatype objects, compatible with the equals methods, such as a.equals(b) iff nf(a) = nf(b). In Python, I know I can handle that beautifully by overriding the hash function.
I don't like the RDF solution. With my solution, Integraal delegates to some java classes the responsability to handle Literals. We will do our best. But if something else is needed, it is possible to change the classes. The normal form is not completely required, but it allows for efficient joins and is necessary if we don't handle ourselves facts storage, but delegate it to another tool like a relational database engine.
Edited by BAGET Jean-Francois
In SQL, if you want to join an INTEGER column with a FLOAT column you need the explicit the cast. See oracle.
So, I tend to believe that the W3C solution is not so unreasonable, for the following reasons.
- Faster comparisons (joins, filters) : do not have to test the type
- Responsibility pushed to the user : the user must know the data she/he is working on !
What I would do, as a compromise :
I would allow the user to :
- use functions for conversion as suggested
- define in DLGP an (optional) signature for certain predicates (no signature == unneeded flexibility and lost optimizations)
We may check also what LogicBlox has done on this matter (just a pointer) https://web.archive.org/web/20230520034645/https://developer.logicblox.com/content/docs4/core-reference/webhelp/primitive-types.html
I think the main problem is not between floating numbers and integers but between integers of different types and floats of different types. This is mainly this that could cause a behavior that is not expected. I think you are right about making the types explicit, it's rare in practice to not know what is the type of what we manipulate. And when we think we know but in fact we have, for example, a source that doesn't always give integers, we want the program to stop and warn the user about that so it can correct its mistake. IMHO, it's one of the main problems of Integraal: we don't have constraints to declare what we expect and stop the program when there's something that is not what we expect. It is difficult to detect and correct mistakes.
mentioned in issue #202
