Loading ...
Sorry, an error occurred while loading the content.

Re: [eiffel-nice-library] 'is_integer' and 'to_integer': a firm proposal

Expand Messages
  • Alexander Kogtenkov
    ... Results from VE: 2147483646 2147483647 -2147483648 1410065407 -2147483646 -2147483647 -2147483648 -1410065407 Regards, Alexander Kogtenkov Object Tools,
    Message 1 of 9 , Jan 3, 2001
    • 0 Attachment
      Roger Browne wrote:

      > I tried it under Halstenbach ibbench 3.1 ("HACT"), and got the following
      > output:
      >
      > 2147483646
      > 2147483647
      > 2147483647
      > 2147483647
      > -2147483646
      > -2147483647
      > -2147483648
      > -2147483648
      >
      > So, HACT converts too-big values to maximum_integer, and too-small
      > values to minimum_integer, without precondition failure or other
      > exception.
      >
      > Would others please try this code on ISE, VE and SE and report the
      > output?

      Results from VE:

      2147483646
      2147483647
      -2147483648
      1410065407
      -2147483646
      -2147483647
      -2147483648
      -1410065407

      Regards,
      Alexander Kogtenkov
      Object Tools, Moscow
    • Roger Browne
      ... Thanks to Johan and Alexander for running this test and reporting the results for SE and VE. In addition to the result that I reported earlier for HACT
      Message 2 of 9 , Jan 3, 2001
      • 0 Attachment
        On 29 December 2000, I wrote:

        > ... For example, how is the following code handled?
        >
        > class MAIN
        > creation make
        > feature make is
        > do
        > print(( "2147483646").to_integer.out + "%N")
        > print(( "2147483647").to_integer.out + "%N")
        > print(( "2147483648").to_integer.out + "%N")
        > print(( "9999999999").to_integer.out + "%N")
        > print(("-2147483646").to_integer.out + "%N")
        > print(("-2147483647").to_integer.out + "%N")
        > print(("-2147483648").to_integer.out + "%N")
        > print(("-9999999999").to_integer.out + "%N")
        > end
        > end

        Thanks to Johan and Alexander for running this test and reporting the
        results for SE and VE. In addition to the result that I reported earlier
        for HACT 3.1, I ran the test for ISE 4.5 and got the same result as for
        HACT 3.1.

        Here are the combined results. The first column is the value of the
        STRING being converted. The second column is the result using ISE and
        HACT, and the third column is the result using VE and SE:

        STRING ISE/HACT VE/SE
        "2147483646" 2147483646 2147483646
        "2147483647" 2147483647 2147483647
        "2147483648" 2147483647 -2147483648
        "9999999999" 2147483647 1410065407
        "-2147483646" -2147483646 -2147483646
        "-2147483647" -2147483647 -2147483647
        "-2147483648" -2147483648 -2147483648
        "-9999999999" -2147483648 -1410065407

        As you can see, all compilers give the same result for values in the
        range minimum_integer to maximum_integer inclusive.

        We could capture the common behaviour by adding a precondition to
        'to_integer', constraining the input string to represent a value between
        2147483647 and -2147483648 inclusive. This could be expressed
        informally, or perhaps formally by exploiting the lexical sort order of
        the STRING using the design suggested by Arno Wagner and others. Does
        anyone want to have a go at formulating this precondition, remembering
        that we must allow for the optional leading zeros and leading sign
        allowed by the BNF?

        A formal or informal precondition along those lines would correctly
        capture the common behaviour of the current compilers, but ideally we
        should strive for a precondition that would abstract out the dependency
        on a 32-bit INTEGER.

        I can't see how to achieve that here (because 'maximum_integer' and
        'minimum_integer' are not available to a precondition of class STRING).
        [Although ETL2 says class ANY inherits from PLATFORM, this was
        explicitly changed in ELKS95, which made PLATFORM a standalone class.]

        If a future language revision adds ISE's "creation expression" extension
        to the Eiffel language, then we would be able to use the values of...

        create {PLATFORM}.minimum_integer
        create {PLATFORM}.maximum_integer

        ...within the expression of a precondition assertion.

        Perhaps someone else can find another way to remove the dependency on a
        32-bit INTEGER. Failing that, we will at least have an informal but
        rigorous specification that captures the common behaviour of all current
        implementations. That's still be a pretty big step forward for
        interoperability.

        Regards,
        Roger
        --
        Roger Browne - roger@... - Everything Eiffel
        19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
      Your message has been successfully submitted and would be delivered to recipients shortly.