This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | terry.reedy |
|---|---|
| Recipients | christian.heimes, mark.dickinson, terry.reedy, tim.peters |
| Date | 2008年03月19日.04:28:40 |
| SpamBayes Score | 0.006991968 |
| Marked as misclassified | No |
| Message-id | <1205900921.32.0.467265438496.issue1811@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
To my mind, the inaccurate result is a bug that should be fixed. Note: (3.0a3) >>> 10e40/10e39 10.0 The rationale for the division change is that (as far as reasonably possible) arithmetic operations with same values should give same result regardless of types. I have not looked at either algorithm, but if long/long started by finding divmod(), but added fractional value when remainer is non-zero instead of tossing it, exact quotients would easily be exact (unless too large). |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年03月19日 04:28:41 | terry.reedy | set | spambayes_score: 0.00699197 -> 0.006991968 recipients: + terry.reedy, tim.peters, mark.dickinson, christian.heimes |
| 2008年03月19日 04:28:41 | terry.reedy | set | spambayes_score: 0.00699197 -> 0.00699197 messageid: <1205900921.32.0.467265438496.issue1811@psf.upfronthosting.co.za> |
| 2008年03月19日 04:28:40 | terry.reedy | link | issue1811 messages |
| 2008年03月19日 04:28:40 | terry.reedy | create | |