Robert Withrow bigbaaad...@gmail.com added the comment:
For completeness: msg131234 states that the issue of 64 bit - 32 bit precision
truncation is covered in the floating point tutorial. I believe that is
incorrect; at least I can't find it explicitly mentioned. Ref:
Mark Dickinson dicki...@gmail.com added the comment:
I don't think this needs to be documented beyond the limitations of
floating-point that are already documented in the tutorial. It's the obvious
behaviour: double to float (when packing) converts to the nearest float; the
float to double
Mark Dickinson dicki...@gmail.com added the comment:
[Robert]
I have to disagree. It seems entirely reasonable to expect that
unpack should return the same value passed to pack.
Robert: notice that a *Python* float (a *64-bit* C double internally) is here
being stored as a *32-bit* float,
Robert Withrow bigbaaad...@gmail.com added the comment:
Martin: in C I have the luxury of using 32 bit floats; not an option in Python.
Simple code doing the moral equivalent of NTOHL(HTONL()) works in this case
for C but wouldn't help for Python.
Mark: I understand about the precision
Martin v. Löwis mar...@v.loewis.de added the comment:
Martin: in C I have the luxury of using 32 bit floats; not an option
in Python. Simple code doing the moral equivalent of NTOHL(HTONL())
works in this case for C but wouldn't help for Python.
If you agree that Python actually behaves
Robert Withrow bigbaaad...@gmail.com added the comment:
If you agree that Python actually behaves correct, I fail to
understand what it is that you disagree with in msg131195
I don't agree that Python is behaving correctly as far as the documented
contract for struct is concerned.
I
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
The suggested examples are misleading because they use 6.24 which is not
exactly representable in binary floating point. Representation issues are
orthogonal to the OP's issue which is really just a simple rounding example:
x
Robert Withrow bigbaaad...@gmail.com added the comment:
it needs to be worded in a way that doesn't
imply that the struct implementation is broken or misdesigned.
Agree.
A better note would focus on the basic (and obvious)
fact that downgrading from double precision to single
precision
Robert Withrow bigbaaad...@gmail.com added the comment:
I have to disagree. It seems entirely reasonable to expect that unpack should
return the same value passed to pack. That it doesn't (as of 2.6.5 at least)
is completely unexpected and undocumented. And yes I understand the
limitations
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4114
___
___
Martin v. Löwis mar...@v.loewis.de added the comment:
Robert: Can you please suggest an algorithm that would have given the result
you expect (preferably as a C program, using a string literal as its input, for
some platform)? Ideally, we would stick to the example given by the OP.
--
TD22057 [EMAIL PROTECTED] added the comment:
That's not my code - it's an example ;)
My code reads binary data from a hardware system that is encoding 32 bit
floats. The numbers I get back from struct.decode have garbage appended
on the end of the floating point numbers beyond the 32 bit
STINNER Victor [EMAIL PROTECTED] added the comment:
I don't understand your problem/question. It's not a bug of Python,
it's a problem of conversion between the types float (32 bits) and
double (64 bits).
___
Python tracker [EMAIL PROTECTED]
TD22057 [EMAIL PROTECTED] added the comment:
I'm receiving a 32 bit floating point number encoded in binary format.
The correct value for that number is 1.8183e-7 which can be expressed in
single precision just fine. Given that the number in the binary
encoding is 1.8183e-7, I expected to get
STINNER Victor [EMAIL PROTECTED] added the comment:
The problem is not from Python but from your FPU during the conversion
from 64 bits float to 32 float (made by struct.pack). Example in C:
#include stdio.h
int main()
{
float f;
double d;
d = 1.8183;
printf(d=%.20f\n, d);
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I think the complaint is that presumably, when expanding the float to
double in unpacking, the result is not zero-padded. I cannot reproduce
the problem, though:
py
hexlify(struct.pack(d,struct.unpack(f,struct.pack(f,1.8183e-7))[0]))
TD22057 [EMAIL PROTECTED] added the comment:
Martin is correct. I expected (naively) that struct would zero pad the
digits beyond the significant digits of a float. As to whether it's
exact or not, see my first message:
v=1.8183e-7
v
1.81830001e-07
Since 32 bit floats only have ~7
STINNER Victor [EMAIL PROTECTED] added the comment:
Since 32 bit floats only have ~7 digits of precision, I expected to
get the same thing back. Not 7 digits + garbage.
This problem is a well known problem of conversion from base 2 (IEEE
float) to base 10 (Python unicode string). Search for
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Python is just reflecting what C is doing: the problem is deeper in
the silicium. If you want a better precision, use an arbitrary
precision float type like decimal.Decimal() or the GMP library
(Python: gmpy)
The problem is indeed
STINNER Victor [EMAIL PROTECTED] added the comment:
@loewis: Yes, the initial problem is about unpack(f, bytes). It's
not possible to exact original 32 bits float value because Python
forces a conversion to 64 bits float. The behaviour should be
documented. Don't hesitate to reopen the bug if
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Don't hesitate to reopen the bug if you consider that
something should be fixed in Python.
I agree that it should be closed; people should read general CS
introductory material to learn how floating point numbers work.
@loewis: Yes, the
21 matches
Mail list logo
