Skip to content

Float patch for inf and nan on Windows (and other platforms) #45976

Closed
Closed
Float patch for inf and nan on Windows (and other platforms)#45976
Assignees
tiran

Description

@tiran
tiran
opened on Dec 15, 2007
BPO 1635
Nosy @gvanrossum, @tim-one, @tiran
Superseder
  • bpo-1640: Enhancements for mathmodule
    		•
    Files
  • trunk_float_inf_nan.patch
  • trunk_float_inf_nan2.patch
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/tiran'
closed_at = <Date 2007-12-18.23:26:07.917>
created_at = <Date 2007-12-15.10:23:24.457>
labels = []
title = 'Float patch for inf and nan on Windows (and other platforms)'
updated_at = <Date 2008-01-06.22:29:44.389>
user = 'https://github.com/tiran'

    bugs.python.org fields:

    activity = <Date 2008-01-06.22:29:44.389>
actor = 'admin'
assignee = 'christian.heimes'
closed = True
closed_date = <Date 2007-12-18.23:26:07.917>
closer = 'christian.heimes'
components = []
creation = <Date 2007-12-15.10:23:24.457>
creator = 'christian.heimes'
dependencies = []
files = ['8961', '8962']
hgrepos = []
issue_num = 1635
keywords = ['patch']
message_count = 12.0
messages = ['58661', '58664', '58697', '58703', '58704', '58759', '58768', '58771', '58776', '58780', '58781', '58785']
nosy_count = 4.0
nosy_names = ['gvanrossum', 'tim.peters', 'Rhamphoryncus', 'christian.heimes']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = '1640'
type = None
url = 'https://bugs.python.org/issue1635'
versions = ['Python 2.6', 'Python 3.0']

    Activity

    1. tiran commented on Dec 15, 2007

      @tiran
      tiran
      on Dec 15, 2007
      MemberAuthor

      The patch unifies the creation and representation of "inf", "-inf" and
      "nan" on all platforms.

      >>> float("inf")
inf
>>> float("-inf")
-inf
>>> float("nan")
nan
>>> repr(1e300 * 1e300)
'inf'
>>> repr(1e300 * 1e300 * 0)
'nan'
>>> repr(1e300 * 1e300 * -1)
'-inf'
    2. tiran
      self-assigned this
      on Dec 15, 2007

    3. tiran commented on Dec 15, 2007

      @tiran
      tiran
      on Dec 15, 2007
      MemberAuthor

      Update:

      I've added a platform independent implementation of stricmp and strnicmp
      (case insensitive compare). It could be useful for other parts of the
      code as well.

    4. Rhamphoryncus commented on Dec 17, 2007

      @Rhamphoryncus
      Rhamphoryncusmannequin
      on Dec 17, 2007
      Mannequin
      You have:
#define Py_NAN Py_HUGE_VAL * 0
I think this would be safer as:
#define Py_NAN (Py_HUGE_VAL * 0)

      For instance, in code that may do "a / Py_NAN".

      Those manual string copies (*cp++ = 'n';) are ugly. Can't you use
      strcpy() instead?

    5. tiran commented on Dec 17, 2007

      @tiran
      tiran
      on Dec 17, 2007
      MemberAuthor

      Adam Olsen wrote:

      You have:
      #define Py_NAN Py_HUGE_VAL * 0
      I think this would be safer as:
      #define Py_NAN (Py_HUGE_VAL * 0)

      For instance, in code that may do "a / Py_NAN".

      You are right! Fixed

      Those manual string copies (*cp++ = 'n';) are ugly. Can't you use
      strcpy() instead?

      Done

      Christian

    6. tiran commented on Dec 17, 2007

      @tiran
      tiran
      on Dec 17, 2007
      MemberAuthor

      I'm posting a combined patch for all features at bpo-1640.

    7. gvanrossum commented on Dec 18, 2007

      @gvanrossum
      gvanrossum
      on Dec 18, 2007
      Member

      Mostly looks good. Here are some nits.

      (1) You shouldn't have to add pystrcmp.c to the VC project files since
      on Windows it isn't used, right?

      (2) Will the Windows input routine still accept the *old*
      representations for INF and NAN? IMO that's important (a) so as to be
      able to read old pickles or marshalled data, (b) so as to be able to
      read data files written by C programs.

      (3) Shouldn't you be using Py_HUGE_VAL instead of HUGE_VAL in the chunk
      starting at line 187 in floatobject.c?

    8. tim-one commented on Dec 18, 2007

      @tim-one
      tim-one
      on Dec 18, 2007
      Member

      [Guido]

      ...
      (2) Will the Windows input routine still accept the *old*
      representations for INF and NAN? IMO that's important (a) so as to be
      able to read old pickles or marshalled data, (b) so as to be able to
      read data files written by C programs.

      Ha! You're such an optimist ;-) The remarkable truth is that Windows
      has never been able to read its own representations for INF and NAN:

      '1.#INF'
>>> float(_)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): 1.#INF
>>> repr(nan)
'-1.#IND'
>>> float(_)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): -1.#IND

      This has nothing to do with Python -- same thing from C, etc.

    9. tiran commented on Dec 18, 2007

      @tiran
      tiran
      on Dec 18, 2007
      MemberAuthor

      Guido van Rossum wrote:

      (1) You shouldn't have to add pystrcmp.c to the VC project files since
      on Windows it isn't used, right?

      It was the easiest way to test the functions in pystrcmp. Linux doesn't
      have stricmp but it also doesn't require the additional code to mangle
      1.#INF into inf.

      (2) Will the Windows input routine still accept the *old*
      representations for INF and NAN? IMO that's important (a) so as to be
      able to read old pickles or marshalled data, (b) so as to be able to
      read data files written by C programs.

      See Tim's answer.
      Pickles and other C programs aren't an issue. Internally NaNs and INFs
      are represented with a special bit pattern (all bits of the exponent are
      set). As long as users don't use str() or repr() on floats it still
      works. The pickle module uses struct.

      (3) Shouldn't you be using Py_HUGE_VAL instead of HUGE_VAL in the chunk
      starting at line 187 in floatobject.c?

      I missed the spot, thanks.

      Christian

    10. tim-one commented on Dec 18, 2007

      @tim-one
      tim-one
      on Dec 18, 2007
      Member

      Historical note: Guido is probably thinking of "the old" pickle and
      marshal here, which did have problems with inf and NaN on Windows (as in
      they didn't work at all). Michael Hudson changed them to use special
      bit patterns instead, IIRC for Python 2.5.

    11. gvanrossum commented on Dec 18, 2007

      @gvanrossum
      gvanrossum
      on Dec 18, 2007
      Member

      Historical note: Guido is probably thinking of "the old" pickle and
      marshal here, which did have problems with inf and NaN on Windows (as in
      they didn't work at all). Michael Hudson changed them to use special
      bit patterns instead, IIRC for Python 2.5.

      In pickle.py, protocol 0 (still the default in 2.6) uses repr(x) to
      write a float and float(s) to convert that back to input. Maybe you're
      thinking of marshal, which is more sophisticated.

    12. gvanrossum commented on Dec 18, 2007

      @gvanrossum
      gvanrossum
      on Dec 18, 2007
      Member

      I suggest you check this in (with the Py_HUGE_VAL fix) and then see how
      much of bpo-1640 we still need.

    13. tiran commented on Dec 18, 2007

      @tiran
      tiran
      on Dec 18, 2007
      MemberAuthor

      Applied in r59558 to the trunk

    14. tiran
      closed this as completedon Dec 18, 2007
    15. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions