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 | mark.dickinson |
|---|---|
| Recipients | christian.heimes, mark.dickinson |
| Date | 2008年01月12日.17:18:53 |
| SpamBayes Score | 0.019197645 |
| Marked as misclassified | No |
| Message-id | <1200158335.31.0.780225180403.issue1811@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
It would be easy and safe to just use a/b = float(a)/float(b) if both a and b are less than 2**53 (assuming IEEE doubles). Then there wouldn't be any loss of speed for small integers. For large integers the algorithm I posted should run in time linear in the number of digits of max(a, b), at least in the worst case (though with appropriate optimizations it could be made much faster for 'random' inputs). The current algorithm has essentially O(1) runtime. To get proper timings I'd have to code this up properly. I'll do this, unless there's a consensus that it would be a waste of time :) |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年01月12日 17:18:55 | mark.dickinson | set | spambayes_score: 0.0191976 -> 0.019197645 recipients: + mark.dickinson, christian.heimes |
| 2008年01月12日 17:18:55 | mark.dickinson | set | spambayes_score: 0.0191976 -> 0.0191976 messageid: <1200158335.31.0.780225180403.issue1811@psf.upfronthosting.co.za> |
| 2008年01月12日 17:18:54 | mark.dickinson | link | issue1811 messages |
| 2008年01月12日 17:18:53 | mark.dickinson | create | |