Odd integer division rounding behavior

[sfrezza]

I had to do odd work-arounds to get integer division to behave normally.

When $totalValue is 1, these two formulations do not compute the same result (I think they should both be zero). See the following DoenetML code snippet:

1 ($totalValue)/2

vs.

($totalValue-0.1)/2

In the first case, $quo0 is set to 1; in the second $quo1 is set to 0. Shouldn't they both compute zero?

In normal rounding or truncation, if the dividend from 1/2 = 0.50 or less, then the integer conversion of this result should be zero. Why in the first case is it 1?

[dqnykamp]

That's fascinating. In your domain, the convention is round 0.5 down to zero? I think it is arbitrary, but I'm more familiar with the convention of rounding 0.5 up to 1!

For the Doenet component <round>, we could always add an attribute to specify the behavior of rounding 0.5. But, for the math function round(x), I can't think of a way to make it flexible, as it would be a strange approach to add an extra argument to determine this behavior.

[sfrezza]

Hi Duane I’ll go look it up but I recall there being a IEEE standard for how this is done in computers. Rounding has three primary styles as I recall. I’ll look it up. If it’s useful, then the terminology the IEEE invented might be useful to you.

Peace, Steve

On Jul 23, 2024, at 8:00 PM, Duane Nykamp @.***> wrote:



Caution: This email originated from outside of FUS. Do not click links, open attachments, or provide any information based on this email unless you know or can verify the sender and know the contents are safe.

That's fascinating. In your domain, the convention is round 0.5 down to zero? I think it is arbitrary, but I'm more familiar with the convention of rounding 0.5 up to 1!

For the Doenet component , we could always add an attribute to specify the behavior of rounding 0.5. But, for the math function round(x), I can't think of a way to make it flexible, as it would be a strange approach to add an extra argument to determine this behavior.

— Reply to this email directly, view it on GitHubhttps://github.com/Doenet/DoenetML/issues/223#issuecomment-2246575303, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AW6NZVGLUU7X4IPR2DFKZC3ZN3VBJAVCNFSM6AAAAABLLMALFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBWGU3TKMZQGM. You are receiving this because you authored the thread.Message ID: @.***>

[dqnykamp]

Doenet definitely started with a focus on math, so I didn't consult IEEE standards.

Just looked up IEEE 754. If one implements roundTiesToEven, then 0.5 should be rounded to 0. If one implements roundTiesToAway, then 0.5 should be rounded to 1.

It looks like for decimal formats, the default is language defined, but they recommend roundTiesToEven. (For binary formats, they require roundTiesToEven.) From section 4.3.3:

The roundTiesToEven rounding-direction attribute shall be the default rounding-direction attribute for results in binary formats. The default rounding-direction attribute for results in decimal formats is language-defined, but should be roundTiesToEven.

I feel like I should consult with additional stakeholders to know how to proceed. If math folks don't have strong opinions, then it would make sense to follow the IEEE recommendations.