From: Alex Young <alex@...>
Date: 2011-09-19T18:49:27+09:00
Subject: [ruby-core:39624] Re: [Ruby 1.9 - Feature #5310] Integral objects

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).
> 
> If anyone have another idea, please give me your comment.
> 
>