Author tim.peters
Recipients Carlos Neves, lemburg, mark.dickinson, rhettinger, stutzbach, tim.peters
Date 2020-07-02.21:22:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
For the first, your hardware's binary floating-point has no concept of significant trailing zeroes. If you need such a thing, use Python's `decimal` module instead, which does support a "significant trailing zero" concept. You would need an entirely new data type to graft such a notion onto Python's (or numpy's!) binary floats.

For the second, we'd have to dig into exactly what numpy's `arange()` does. Very few of the numbers you're working with are exactly representable in binary floating point except for 0.0. For example, "0.001" is approximated by a binary float whose exact decimal value is


Sometimes the rounded (by machine float arithmetic) multiples of that are exactly representable, but usually not. For example,

>>> 0.001 * 250

rounds to the exactly representable 1/4, and

>>> 0.001 * 750

to the exactly representable 3/4. However, `round()` uses round-to-nearest/even, and then

>>> round(0.25, 1)
>>> round(0.75, 1)

both resolve the tie to the closest even value (although neither of those _results_ are exactly representable in binary floating-point - although if you go on to multiply them by 10.0, they do round (in hardware) to exactly 2.0 and 8.0).

Note that numpy's arange() docs do warn you against using it ;-)

When using a non-integer step, such as 0.1, the results will often not be consistent. It is better to use numpy.linspace for these cases.
Date User Action Args
2020-07-02 21:22:30tim.peterssetrecipients: + tim.peters, lemburg, rhettinger, mark.dickinson, stutzbach, Carlos Neves
2020-07-02 21:22:30tim.peterssetmessageid: <>
2020-07-02 21:22:30tim.peterslinkissue41198 messages
2020-07-02 21:22:30tim.peterscreate