Re: [gobo-eiffel-develop] Usage of INTEGER_64

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> We drop VE completely. If it's not for INTEGER_64, it will
>     Eric> be for Agents/Tuples. So let's drop it now.
> 
> OK.
> 
> There appears to be a problem with gec.
> 
> I have the following tests, which se and ise (5.7) pass:
> 
> 	test_is_integer_64 is
> 			-- Test feature `is_integer_64'.
> 		local
> 			uc_string: UC_UTF8_STRING
> 		do
> 			assert ("is_integer_64_1", STRING_.is_integer_64 ("1234"))
> 			assert ("is_integer_64_2", STRING_.is_integer_64 ("00078"))
> 			create uc_string.make_from_string ("4534")
> 			assert ("is_integer_64_3", STRING_.is_integer_64 (uc_string))
> 			assert ("is_integer_64_4", STRING_.is_integer_64 ("9223372036854775807"))
> 			assert ("is_integer_64_5", STRING_.is_integer_64 ("00000000009223372036854775807"))
> 			assert ("not_is_integer_64_1", not STRING_.is_integer_64 ("9223372036854775808"))
> 			assert ("not_is_integer_64_2", not STRING_.is_integer_64 ("10223372036854775807"))
> 			assert ("not_is_integer_64_1", not STRING_.is_integer_64 ("00019223372136854775807"))
> 		end
> 
> 	test_to_integer_64 is
> 			-- Test feature `to_integer_64'.
> 		local
> 			uc_string: UC_UTF8_STRING
> 		do
> 			assert_equal ("to_integer_64_1", (1234).to_integer_64, STRING_.to_integer_64 ("1234"))
> 			assert_equal ("to_integer_64_2", (78).to_integer_64, STRING_.to_integer_64 ("00078"))
> 			create uc_string.make_from_string ("4534")
> 			assert_equal ("to_integer_64_3", (4534).to_integer_64, STRING_.to_integer_64 (uc_string))
> 			assert_equal ("to_integer_64_4", (9223372036854775807).to_integer_64, STRING_.to_integer_64 ("9223372036854775807"))
> 			assert_equal ("to_integer_64_5", (9223372036854775807).to_integer_64, STRING_.to_integer_64 ("00000000009223372036854775807"))
> 		end
> 
> Gec fails one:
> 
> Test Results:
> FAIL:  [KL_TEST_STRING_ROUTINES.test_to_integer_64] to_integer_64_4
>    expected: -1
>    but  got: 9223372036854775807
> 
> so it looks like GEC's built-in {INTEGER}.to_integer_64 is off by one
> on the edge case.

This might be surprising at first, but the other compilers are wrong.
According to ECMA Eiffel, the number 9223372036854775807 in
(9223372036854775807).to_integer_64 is of type INTEGER. Therefore
this cannot work. The problem with GEC (and with the other compilers)
is that it should have reported an error at compile time.

The ECMA way to do it is:

       {INTEGER_64} 9223372036854775807

but this won't work with SE I think.

Note that I'm surprised that `assert_equal' in your test above works
with SE. It accepts ANY as arguments and in SE expanded types (such
as INTEGER_64) don't conform to ANY. That's why we introduced
`assert_integers_equal', `assert_characters_equal', etc. Or do
SE 1.2 and 2.* have a different behavior with this respect?

One way (which is not 100% ECMA compliant but would work with
all Eiffel compilers would be to introduce a routine
`assert_integer_64_equal' and write:

assert_integer_64_equal ("to_integer_64_4", 9223372036854775807, 
STRING_.to_integer_64 ("9223372036854775807"))

Here it works because the compilers know that the expected type
for 9223372036854775807 (the type of the formal argument of
the routine) is INTEGER_64. Likewise, this would work:

   i64: INTEGER_64
   ...
   i64 := 9223372036854775807
   assert_equal ("to_integer_64_4", i64, STRING_.to_integer_64 
("9223372036854775807"))

We could also have a feature:

     maximum_integer_64: INTEGER_64

in class KL_PLATFORM. This latter solution would probably be better.


I had a look at the routines `is_integer_64' and `to_integer_64'
in class KL_STRING_ROUTINES. And there are two things that I don't
like. The first thing is that they create too many temporary
objects (calling `substring', creating manifest arrays). I know
that Eiffel is a language equipped with GC, but the less work we
give to the GC, the faster the program will run. The second thing
that I don't like is the precondition "is_integer". I don't think
that it is a good idea to have to write:

    is_integer (s) and then is_integer_64 (s)

On the other hand "is_integer" should be a postcondition of
`is_integer_64':

    Result implies is_integer (a_string)

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com