Mark Dickinson wrote: > I'd like to propose two minor changes to float and complex > formatting, for 3.1. I don't think either change should prove > particularly disruptive. > > (1) Currently, '%f' formatting automatically changes to '%g' formatting for > numbers larger than 1e50. For example: ... > I propose removing this feature for 3.1 I'm +1 on this. > I have a suspicion that at least part of the > motivation for the '%f' -> '%g' switch is that it means the > implementation can use a fixed-size buffer. But Eric has > fixed this (in 3.1, at least) and the buffer is now dynamically > allocated, so this isn't a concern any more. I agree that this is a big part of the reason it was done. There's still some work to be done in the fallback code which we use if we can't use Gay's implementation of _Py_dg_dtoa. But it's reasonably easy to calculate the maximum buffer size needed given the precision, for passing on to PyOS_snprintf. (At least I think that sentence is true, I'll very with Mark offline). > Other reasons not to switch from '%f' to '%g' in this way: > > - the change isn't gentle: as you go over the 1e50 boundary, > the number of significant digits produced suddenly changes > from 56 to 6; it would make more sense to me if it > stayed fixed at 56 sig digits for numbers larger than 1e50. This is the big reason for me. > - float formatting is already quite complicated enough; no > need to add to the mental complexity And this, too. > (2) complex str and repr don't behave like float str and repr, in that > the float version always adds a trailing '.0' (unless there's an > exponent), but the complex version doesn't: ... > I propose changing the complex str and repr to behave like the > float version. That is, repr(4. + 10.j) should be "(4.0 + 10.0j)" > rather than "(4+10j)". I'm +0.5 on this. I'd probably be +1 if I were a big complex user. Also, I'm not sure about the spaces around the sign. If we do want the spaces there, we can get rid of Py_DTSF_SIGN, since that's the only place it's used and we won't be able to use it for complex going forward. Eric.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4