Author tim.peters
Recipients mark.dickinson, rhettinger, steven.daprano, tim.peters
Date 2021-11-26.18:49:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1637952575.16.0.529743387951.issue45876@roundup.psfhosted.org>
In-reply-to
Content
Mark, ya, MS's Visual Studio's ldexp() has, far as I know, always worked this way. The code I showed was run under the 2019 edition, which we use to build the Windows CPython.

Raymond,

    x = float(i)

is screamingly obvious at first glance.

    x = i/1
    
looks like a coding error at first. The "reason" for different spellings in different branches looked obvious in the original: one branch needs to divide, and the other doesn't. So the original code was materially clearer to me.

Both, not sure it helps, but this use of round-to-odd appears akin to the decimal module's ROUND_05UP, which rounds an operation result in such a way that, if it's rounded again - under any rounding mode - to a narrower precision, you get the same narrower result as if you had used that rounding mode on the original operation to that narrower precision to begin with.

Decimal only needs to adjust the value of the last retained digit to, effectively, "encode" all possibilities, but binary needs two trailing bits. "Round" and "sticky" are great names for them :-)
History
Date User Action Args
2021-11-26 18:49:35tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, steven.daprano
2021-11-26 18:49:35tim.peterssetmessageid: <1637952575.16.0.529743387951.issue45876@roundup.psfhosted.org>
2021-11-26 18:49:35tim.peterslinkissue45876 messages
2021-11-26 18:49:35tim.peterscreate