[
https://issues.apache.org/jira/browse/DAFFODIL-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490576#comment-16490576
]
Russ Williams commented on DAFFODIL-1714:
-----------------------------------------
The ULong modulus code is simply wrong... it calculates (x/2)%y == x%(2y),
which is necessary to use signed longs for unsigned values, but then doesn't
calculate (x%(2y))%y == x%y. The commented-out line performs the appropriate
adjustment for the quotient, the equivalent for the remainder would be to
subtract d from the result if ULong(r) >= ULong(d).
I've added (originally failing) test cases for the correct behaviour, and
implemented the fix.
> ULong modulus operator broken
> -----------------------------
>
> Key: DAFFODIL-1714
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1714
> Project: Daffodil
> Issue Type: Bug
> Components: General, Libraries
> Affects Versions: 2.0.0
> Reporter: Steve Lawrence
> Assignee: Russ Williams
> Priority: Major
> Fix For: deferred
>
>
> It appears that the ULong modulus operator is broken. If we run this code:
> {code}
> for (i <- 0 to 16 ) {
> val numerator = ULong(i)
> val denominator = ULong(8)
> val remainder = numerator % denominator
> println(i + " % 8 = " + remainder)
> }
> {code}
> we get the result:
> {code}
> 0 % 8 = 0
> 1 % 8 = 1
> 2 % 8 = 2
> 3 % 8 = 3
> 4 % 8 = 4
> 5 % 8 = 5
> 6 % 8 = 6
> 7 % 8 = 7
> 8 % 8 = 8
> 9 % 8 = 9
> 10 % 8 = 10
> 11 % 8 = 11
> 12 % 8 = 12
> 13 % 8 = 13
> 14 % 8 = 14
> 15 % 8 = 15
> 16 % 8 = 0
> {code}
> Anything % 8 should always be less than 8. But some results are greater than
> 8. Not sure exactly what is going on, and the generated bytecode is really
> hard to follow. In fact, I wouldn't be surprised if ULongs are actually
> slowing things down. The byte code was kindof a mess. We might want to
> revisit ULongs and how else to support > 4GB files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
