The floatformat template tag doesn't work with a value of 0 and a precision of 7 or higher.

[Tai Lee]

>>> floatformat(0.123456789, 6)
u'0.123457'
>>> floatformat(0.123456789, 7)
u'0.1234568'
>>> floatformat(0.0, 6)
u'0.000000'
>>> floatformat(0.0, 7)
u'0E-7'

Looks like the Decimal module (which floatformat uses to perform accurate rounding) is causing trouble.

>>> Decimal('0.123456789').quantize(Decimal('1.000000'))
Decimal("0.123457")
>>> Decimal('0.123456789').quantize(Decimal('1.0000000'))
Decimal("0.1234568")
>>> Decimal('0.0').quantize(Decimal('1.000000'))
Decimal("0.000000")
>>> Decimal('0.0').quantize(Decimal('1.0000000'))
Decimal("0E-7")

[Tai Lee]

Failing test case.

[Facundo Batista]

Note that the behaviour of Decimal module in that case is correct.

The Decimal Specification [0], in the "to-scientific-string – conversion to numeric string" section, says:

"""
If the exponent is less than or equal to zero and the adjusted exponent is greater than or equal to -
6, the number will be converted to a character form without using exponential notation.
...
Otherwise (that is, if the exponent is positive, or the adjusted exponent is less than -6), the number
will be converted to a character form using exponential notation.
"""

[0] ​http://speleotrove.com/decimal/

[Carl Meyer]

I'm going to move this to Accepted, on the basis that even though the current behavior follows Decimal and may be correct according to some standard, I highly doubt that it would ever be the desired behavior in a real usage of floatformat. I think it's pretty low priority, though, and would need to see a working patch without any obvious major downsides (including the implementation being hugely complex and potentially difficult to maintain).

I don't feel strongly about this, and would be pretty open to an argument for wontfix.

[Tai Lee]

Just uploaded a patch that fixes this with tests. It reconstructs the number from the DecimalTuple object to avoid conversion into scientific format. I don't think the implementation is too complex or difficult to maintain. I don't think docs are needed as this is a fix to unexpected behaviour.

[Tai Lee]

Updated the patch to use a list comprehension and consistent unicode strings as per brodie's feedback in #django-sprint.

[Adam Nelson]

It seems like the simpler solution is to use ​.normalize(). I could be wrong though - I haven't gone through all the possible decimal/float issues

>>> Decimal('0.0').quantize(Decimal('1.000000000'))
Decimal('0E-9')
>>> Decimal('0.0').quantize(Decimal('1.000000000')).normalize()
Decimal('0')

[Tai Lee]

Decimal.normalize() strips trailing zeroes (and the decimal point), and still converts some numbers to scientific notation.

>>> decimal.Decimal('0.0000001').normalize()
Decimal('1E-7')

[Adam Vandenberg]

As a possibly unrelated side note, dealing with Decimal values in the external MS SQL Server backend gives us no end of grief: ​http://code.google.com/p/django-mssql/source/browse/sqlserver_ado/dbapi.py?r=2451845d9bf8c77746f569d10dae417d26d6c24f#179

We end up using "as_tuple" and counting string lengths.

[Ramiro Morales]

Patch looks correct, Decimal-related code modification got positive review by Facundo Batista (Decimal module co-maintainter).

[Ramiro Morales]

In [15736]:

Fixed #11206 -- Ensure that the floatformat template filter doesn't switch to scientific notation when asked to format a zero value with more than six decimal places. Thanks Tai Lee for the report and fix and Facundo Batista for his help when Decimal module expertise was needed.

[Ramiro Morales]

In [15738]:

[1.2.X] Fixed #11206 -- Ensure that the floatformat template filter doesn't switch to scientific notation when asked to format a zero value with more than six decimal places. Thanks Tai Lee for the report and fix and Facundo Batista for his help when Decimal module expertise was needed.

Backport of [15736] from trunk

[Jacob]

Milestone 1.3 deleted