[ 
https://issues.apache.org/jira/browse/JENA-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367135#comment-17367135
 ] 

Andy Seaborne commented on JENA-2116:
-------------------------------------

The report is using decimal divide to achieve a "remainder" operation. This has 
been split into JENA-2122 to provide {{mod}} and {{idiv}}.

The decimal divide with arbitrary precision JENA-1943 uses an exception when 
the decimal result can not be exactly represented. This seems unavoidable.

It triggered in the report because the "divide by 7200" is not exact in XSD 
decimal (factor of 3).

A partial optimization to not create unnecessary lexical forms (the value 
result is need, the lexical form is not) can be added. This makes an 
approximately 20% improvement.

Otherwise the change from JENA-143 remains in-place.


> Performance regression in xsd:decimal division.
> -----------------------------------------------
>
>                 Key: JENA-2116
>                 URL: https://issues.apache.org/jira/browse/JENA-2116
>             Project: Apache Jena
>          Issue Type: Bug
>          Components: ARQ
>    Affects Versions: Jena 3.17.0, Jena 4.0.0, Jena 4.1.0
>            Reporter: Andy Seaborne
>            Assignee: Andy Seaborne
>            Priority: Major
>
> [Report from users@ : 
> 2021-06-04|https://lists.apache.org/thread.html/ra55320e0f0f63364093d100fde3083e73065cab4bdbdcb693f8fe95c%40%3Cusers.jena.apache.org%3E]
> As a result of JENA-1943, Java BigDecimal division will cause an 
> ArithmeticException when then is no exact decimal result. In the report, 
> division by 3 will mean no exact answer.
> But the change in JENA-1943 (arbitray precision for exact answers) is also 
> desirable. Simply having a quite large division precise (e.g. 100) isn't 
> ideal because e.g. {{1/3}} returns {{0.333333333333333333333333}} (precision 
> of 24) currently, not {{0.3333......}} length about 100.
> Also, there is an unnecessary canonicalization of a value that is only used 
> in further calculation so the lexical form isn't needed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to