[issue39335] round Decimal edge case
New submission from Hrvoje Abraham :
>>> from decimal import Decimal
>>> round(Decimal('-123.49'))
-124.0
I would expect -123.0, even considering Py2 rounding convention details (away
from zero), Decimal rounding convention (default rounding=ROUND_HALF_EVEN),
floating point specifics...
Works as expected in Py3. Both Py2 and Py3 use same default Decimal
rounding=ROUND_HALF_EVEN.
Could be I'm missing some detail...
--
components: Library (Lib)
messages: 35
nosy: ahrvoje
priority: normal
severity: normal
status: open
title: round Decimal edge case
versions: Python 2.7
___
Python tracker
<https://bugs.python.org/issue39335>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment: IEEE & C/C++ standards allow and explicitly mention it, some people and projects are using it, many compilers preserve it... I believe it's reasonable to support it despite the fact it does not have standardized semantic meaning. Maybe one day... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment: Sage: http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/complex_number.html >>> log(ComplexNumber(NaN,1)) NaN - NaN*I -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment:
Regarding NaN sign bit, IEEE-754 states:
"Note, however, that operations on bit strings—copy, negate, abs,
copySign—specify the sign bit of a NaN result, sometimes based upon the sign
bit of a NaN operand. The logical predicate totalOrder is also affected by the
sign bit of a NaN operand."
So NaN sign bit information is used in the standard itself (section 5.10.d):
1) totalOrder(−NaN, y) is true where −NaN represents a NaN with negative sign
bit and y is a
floating-point number.
2) totalOrder(x, +NaN) is true where +NaN represents a NaN with positive sign
bit and x is a
floating-point number.
This fact alone implies the importance of its round-trip safety. I believe the
quote you picked states this information doesn't have universal (standardized)
meaning, not it is not important or used at all. It is reasonable to assume
some will need to preserve it.
There are also some real-life usages, similar as signed zero, in determining
the correct complex plane branch cut:
http://stackoverflow.com/questions/8781072/sign-check-for-nan-value
http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/catan.3M.html
catan(inf + iNAN) => π/2 + i0; catan(inf - iNAN) => π/2 - i0;
MSVC 2015 and MinGW-W64 v4.9.2 output (source below) for '-nan' values are:
MSVC: -nan(ind)
MinGW-W64: -1.#IND00
#include
int main()
{
double x = 0.0;
x = - x / x;
printf("%lf\n", x);
return 0;
}
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment:
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:40:30) [MSC v.1500 64 bit
(AMD64)] on win32:
>>> import struct
>>> x=float("-nan")
>>> struct.pack('<d', x)
'\x00\x00\x00\x00\x00\x00\xf8\x7f'
Looks like the sign bit is off (0) in 2.7.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
Hrvoje Abraham added the comment:
Reported issue was created in 64-bit Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6
2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32.
Now I noticed that in Py 2.7 even copysign part does not work as expected.
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec 5 2015, 20:40:30) [MSC v.1500 64 bit
(AMD64)] on win32:
>>> from math import copysign
>>> x = float("-nan")
>>> copysign(1.0, x)
1.0
Not correct.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26785] repr of -nan value should contain the sign
New submission from Hrvoje Abraham:
repr of -nan value should contain the sign so the round-trip could be assured.
NaN value sign (bit) could be seen as not relevant or even uninterpretable
information, but it is actually used in real-life situations, the fact
substantiated by section 6.3 of IEEE-754 2008 standard.
>>> from math import copysign
>>> x = float("-nan")
>>> copysign(1.0, x)
-1.0
This is correct. Also proves the value contains the sign information.
>>> repr(x)
nan
Not correct. Should be '-nan'.
--
components: Interpreter Core
messages: 263576
nosy: ahrvoje
priority: normal
severity: normal
status: open
title: repr of -nan value should contain the sign
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26785>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24663] ast.literal_eval does not handle empty set literals
Hrvoje Abraham added the comment: For now I'll implement my_literal_eval via AST filtering, reproducing ast.literal_eval + 'set()' functionality. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24663] ast.literal_eval does not handle empty set literals
Hrvoje Abraham added the comment: I use communication protocol based on Python literals and ast.literal_eval for deserialization. I'm avoiding sets because empty set value is not supported in a clean consistent manner on language level. If I write repr(set()) i get 'set()', this should matter, maybe. I know I can handle it as a special case, None for empty set, and close my eyes on fact that I lose None value reserved for some other cases. But this really is not a nice thing to do. Please reconsider... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24663] ast.literal_eval does not handle empty set literals
Hrvoje Abraham added the comment: I believe this is the issue. ast.literal_eval sets support can not be considered complete until it also handles empty sets. I do not consider it valid for me to explicitly handle this case in my projects using some weird hacks. Python community settled on not introducing empty set literal because one can simply use set(), as discussed a few times before. But no corresponding alternative was defined for ast.literal_eval, maybe it should handle 'set()' as such. I strongly advise reopening this issue and finding functional solution for empty set case. I need it! -- nosy: +ahrvoje type: -> enhancement versions: +Python 3.5 -Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
