New submission from Noam Raphael <[EMAIL PROTECTED]>:
Hello,
The documentation of the tokenize module says: "The line passed is the
*logical* line; continuation lines are included."
Some background: The tokenize module splits a python source into tokens,
and says for each token
Noam Raphael <[EMAIL PROTECTED]> added the comment:
Can I suggest that you also add something like "The row indices in the
(row, column) tuples, however, are physical, and don't treat
continuation lines specially."?
It's just that it took me some time to understand you
New submission from Noam Raphael :
Hello,
This bug is the cause of a bug reported about DreamPie:
https://bugs.launchpad.net/bugs/530969
DreamPie (http://dreampie.sourceforge.net) changes sys.displayhook so that
values will be sent to the parent process instead of being printed in stdout
Noam Raphael added the comment:
I don't know, for me it works fine, even after downloading a fresh SVN
copy. On what platform does it happen?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Noam Raphael added the comment:
I also use linux on x86. I think that byte order would cause different
results (the repr of a random float shouldn't be "1.0".)
Does the test case run ok? Because if it does, it's really strange.
--
ve
Noam Raphael added the comment:
Oh, this is sad. Now I know why Tcl have implemented also a decimal to
binary routine.
Perhaps we can simply use both their routines? If I am not mistaken,
their only real dependency is on a library which allows arbitrary long
integers, called tommath, from which
Noam Raphael added the comment:
The Tcl code can be fonund here:
http://tcl.cvs.sourceforge.net/tcl/tcl/generic/tclStrToD.c?view=markup
What Tim says gives another reason for using that code - it means that
currently, the compilation of the same source code on two platforms can
result in a code
Noam Raphael added the comment:
I think that for str(), the current method is better - using the new
repr() method will make str(1.1*3) == '3.3003', instead of
'3.3'. (The repr is right - you can check, and 1.1*3 != 3.3. But for
str() purposes it's fine.)
Noam Raphael added the comment:
If I think about it some more, why not get rid of all the float
platform-dependencies and define how +inf, -inf and nan behave?
I think that it means:
* inf and -inf are legitimate floats just like any other float.
Perhaps there should be a builtin Inf, or at
Noam Raphael added the comment:
That's right, but the standard also defines that 0.0/0 -> nan, and
1.0/0 -> inf, but instead we raise an exception. It's just that in
Python, every object is expected to be equal to itself. Otherwise, how
can I check if
Noam Raphael added the comment:
If I understand correctly, there are two main concerns: speed and
portability. I think that they are both not that terrible.
How about this:
* For IEEE-754 hardware, we implement decimal/binary conversions, and
define the exact behaviour of floats.
* For non-IEEE
Noam Raphael added the comment:
If I were in that situation I would prefer to store the binary
representation. But if someone really needs to store decimal floats,
we can add a method "fast_repr" which always calculates 17 decimal
digits.
Decimal to binary conversion, in any case, sh
Noam Raphael added the comment:
Ok, so if I understand correctly, the ideal thing would be to
implement decimal to binary conversion by ourselves. This would make
str <-> float conversion do the same thing on all platforms, and would
make repr(1.1)=='1.1'. This would also al
Noam Raphael added the comment:
2007/12/13, Guido van Rossum <[EMAIL PROTECTED]>:
>
> > Ok, so if I understand correctly, the ideal thing would be to
> > implement decimal to binary conversion by ourselves. This would make
> > str <-> float conversion do the
Noam Raphael added the comment:
Ok, I think I have a solution!
We don't really need always the shortest decimal representation. We just
want that for most floats which have a nice decimal representation, that
representation will be used.
Why not do something like that:
def newrepr(f):
Noam Raphael added the comment:
I think that we can give up float(repr(x)) == x across different
platforms, since we don't guarantee something more basic: We don't
guarantee that the same program doing only floating point operations
will produce the same results across different 754
Noam Raphael added the comment:
2007/12/18, Raymond Hettinger <[EMAIL PROTECTED]>:
> The 17 digit representation is useful in that it suggests where the
> problem lies. In contrast, showing two numbers with reprs of different
> lengths will strongly suggest that the shorter
Noam Raphael added the comment:
About the educational problem. If someone is puzzled by "1.1*3 !=
3.3", you could always use '%50f' % 1.1 instead of repr(1.1). I don't
think that trying to teach people that floating points don't always do
what they expect them t
Noam Raphael added the comment:
I just wanted to say that I'm not going to bother too much with this
right now - Personally I will just use epydoc when I want to create an
HTML documentation. Of course, you can still do whatever you like with
the patch.
Good luck,
Noam
--
nosy:
New submission from Noam Raphael :
Hello,
This is from the current svn:
> ./python
Python 3.2a0 (py3k:76104, Nov 4 2009, 08:49:44)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
Noam Raphael added the comment:
I'm sorry, but it seems to me that the conclusion of the discussion in
2008 is that the algorithm should simply use the system's
binary-to-decimal routine, and if the result is like 123.456, round it
to 15 digits after the 0, check if the result evalua
Noam Raphael added the comment:
Do you mean msg58966?
I'm sorry, I still don't understand what's the problem with returning
f_15(x) if eval(f_15(x)) == x and otherwise returning f_17(x). You said
(msg69232) that you don't care if float(repr(x)) == x isn't
cross-platfo
22 matches
Mail list logo
