为什么Jean和Sesame/OpenRDF的SPARQL处理器对除法运算的解释会发生变化？

以下SPARQL查询在两个流行SDK（和）的SPARQL引擎上运行时会产生不同的结果：

另一方面，最新版本的Sesame/OpenRDF返回（为可读性而格式化）：

v1：“0”^^
v2:“0.0”^^
v3:“0.3333 4”^^
v4:“0.3”^^
v5：“0.3”^^
v6:“0.3333 4”^^

---

要强调这一点：Jena从未像Sesame/OpenRDF那样返回0、0.0或0.3。有人能解释一下为什么数值结果会有如此大的差异吗？如何对相同的SPARQL查询获得相同的结果？或者，哪一个是正确的（从正确实施SPARQL标准的意义上讲，不管数学正确性如何）？

这种差异是由Sesame实施除法运算符时采用的不同舍入/缩放策略解释的

第一个操作员：

1 / 3 as ?v

将两个整数值相除，并将结果绑定到？v，该值将是十进制类型的值

由于1/3是具有非终止小数展开的分数，我们需要对结果进行四舍五入。但是，由于两个输入变量的小数位数（即小数位数）为零，Sesame的MathUtil也将结果的小数位数设置为零，因此除法结果（0.3333…）被缩放为零位数并四舍五入，结果为0

您可以在Sesame中通过显式地向输入值添加比例来解决这个问题。例如：

SELECT  ?v1 
WHERE
{
    BIND ( 1.0000 / 3 as ?v1)
}

将导致：

?v1:  "0.3333"^^<http://www.w3.org/2001/XMLSchema#decimal>    

？v1:“0.3333”^

请注意，我们在这里实际做的是将一个输入值从整数更改为十进制。这有点类似于在Java中执行1/3将导致0，但您可以通过强制转换为double来绕过这一点

从XPath规范（定义SPARQL重用的除法运算符）可以看出，Jena和Sesame的行为都符合规范，因为数字操作的缩放数选择是由实现定义的

---

当然，这并不是说如果Sesame在除法时对这些重复分数使用更高的精度，它就不会更实际。作为改进请求记录在，因为这是一件小事，所以在下一个版本中将支持此操作。同时，我希望以上内容能为您提供一个合适的解决方案

感谢您的解释和改进请求。一个问题：位数是否会影响算术精度？我认为不应该这样，OpenRDF/Sesame似乎就是这样。好吧，这取决于你如何看待它。在某种意义上，我们使用的任何精度都是任意的，因为它始终是实际值的近似值。在进行统计时，依赖输入的精度是很正常的：任何结果怎么可能比作为输入提供的数据更精确？但正如我所说的：对重复分数使用较大的固定精度当然比单纯依赖输入精度更实际。

1 / 3 as ?v

SELECT  ?v1 
WHERE
{
    BIND ( 1.0000 / 3 as ?v1)
}

?v1:  "0.3333"^^<http://www.w3.org/2001/XMLSchema#decimal>