```On 18/09/11 11:07, Alexey Muranov wrote:
>
> Issue #5310 has been updated by Alexey Muranov.
>
>
> Hello, i also do not understand very well the issue.
>
> Am i right that it has to do with the difference between #to_int and #to_i methods, similar to the difference between #to_ary and #to_a methods?
> Do i understand correctly that #to_a is a conversion to an Array of anything that can be converted, and #to_ary is an "easy conversion to Array" reserved for objects that are essentially arrays, and similarly #to_int is reserved for objects that are essentially integers?
> In this case i agree with the proposal: to convert a Float to Integer, only #to_i should be allowed, because Floats store approximate values, and Integers store exact values, so Floats are not "essentially" Integers.

This reasoning is precisely wrong. Floats *do not* store approximate
values. Floats store *precise* values.  It is the *operations* on Floats
which are potentially inaccurate.

Put another way:  Float(1) is a mathematical integer. It makes no sense
to say that 1 != 1.to_f.

If I understand the issue correctly, then what is being argued for is,
for instance, that:

[:a, :b, :c][1.6]

should raise an error rather than returning :b.  I can see that there is
an argument that this is ambiguous, because it could legitimately return
:c instead if to_int on a Float rounded up, but that's a matter of
specification.  I can't see that this should be an error condition.

--
Alex

>
> I think it would be nice if the rule for using #to_ary and #to_int would be the following: conversion back and forth (if a corresponding inverse conversion exists) should always return the same value.
> Also the conversion should when possible commute with some operations: sum, concatenation, etc.
> Currently i get: (10000000000000000.to_f+1.to_f).to_int #=> 10000000000000000
> (but of course #to_f is not an "easy conversion", so this in not wrong).
> Probably this is impossible to observe exactly, but maybe to some extent?
> This is just an idea.
>
> Alexey.
> ----------------------------------------
> Feature #5310: Integral objects
> http://redmine.ruby-lang.org/issues/5310
>
> Author: Kenta Murata
> Status: Open
> Priority: Normal
> Assignee:
> Category: core
> Target version: 2.0
>
>
> I believe it is ambiguous what object can behave as an integral number.
> I don't think the current use of Object#to_int isn't appropriate for this purpose.
>
> The most understandable example is Float#to_int.
> It should raise error for all float values because they always have uncertainty,
> but it doesn't and returns an integral part of it.
>
> I propose to change the use of Object#to_int for the next release of Ruby.
> I recommend the following specification changes:
>
> (1) Remove to_int method from Float and BigDecimal.
> (2) Rational#to_int returns an Integer only if its denominator is 1. Otherwise, it raises an appropriate error.
> (3) Complex#to_int returns the result of to_int of its real part only if its imaginary part is exactly zero (0.0 isn't exactly zero).
>