Add exponential formatting to BigInt#214
Add exponential formatting to BigInt#214PatrickNorton wants to merge 6 commits intorust-num:masterfrom
Conversation
src/biguint.rs
Outdated
| } else { | ||
| // The max digits that can fit into a f64, which ensures | ||
| // that printing won't have rounding errors. | ||
| const MAX_FLOAT_DIGITS: usize = 14; |
There was a problem hiding this comment.
f64::DIGITS is 15, though it does say "approximate". Perhaps we should us that, minus one?
There was a problem hiding this comment.
I subtracted 1 to ensure the rounding wouldn't turn out weird, but forgot to update the docs. I didn't know f64::DIGITS existed, so I'll update to take that into account.
| buffer.push('.'); | ||
| for &ch in iter.take(precision) { | ||
| buffer.push(ch as char); | ||
| } |
There was a problem hiding this comment.
Don't we need rounding if there were more digits than the precision required?
There was a problem hiding this comment.
Good point! Added.
| } | ||
| buffer.push(if upper { 'E' } else { 'e' }); | ||
| write!(buffer, "{}", digits.len() - 1)?; | ||
| f.pad_integral(is_nonneg, "", &buffer) |
There was a problem hiding this comment.
pad_integral feels weird in this case, but I'm not sure it's wrong. The standard library uses its internal pad_formatted_parts for exponential integers, but at a glance I don't see what would be different.
There was a problem hiding this comment.
It's definitely weird, but it does seem to do the right thing. I've added a comment to that effect.
|
Would this PR be merged soon? I'm looking for similar functionality on this. |
3 participants
Should close #6.