Currently #asInteger truncates. There is a method in Number>>#detentBy: detent atMultiplesOf: grid snap: snap

"Map all values that are within detent/2 of any multiple of grid to that multiple. Otherwise, if snap is true, return self, meaning that the values in the dead zone will never be returned. If snap is false, then expand the range between dead zones so that it covers the range between multiples of the grid, and scale the value by that factor."

Which is essential when dealing with Floats equality with other numbers.

A lot else is caught up in the poor implementation and overall imprecision of squeak. Nicolas is one of the few who try to be careful and precise. The main implementors are willing to sacrifice precision for overall code speed and a certain care for not tackling time consuming coding problems. Retrofitting asInteger would touch a lot of code that has already warped itself to work around the truncation.

The trade-off between precision and speed is real. Large integers and fractions require operations way slower than Floats. As a result of the value for code speed a lot of off by one and cumulative rounding errors have set in. I do not know what can be done about it in the time programmers have to work on projects that come out of their "spare" time.

Sorry for the discouraging note. Recent experiences have left me a little discouraged.

Yours in curiosity and service (mostly), --Jerome Peace

--- On Mon, 6/27/11, nicolas cellier nicolas.cellier.aka.nice@gmail.com wrote:

From: nicolas cellier nicolas.cellier.aka.nice@gmail.com Subject: [Newbies] Re: asInteger bug? To: beginners@lists.squeakfoundation.org Date: Monday, June 27, 2011, 2:56 PM bb <bblochl <at> arcor.de> writes:

...

There I found a problem with asInteger:

According to the x3j20 ansi standard

Float>>asInteger and

...

Double>>asInteger should be equivalent to

sending rounded. You can

...

download the final draft revision for free:

wiki.squeak.org/squeak/uploads/172/standard_v1_9-indexed.pdf.

...

I tried that in squeak 4.2: 1.11 asInteger 1 1.99 asInteger 1 1.11 rounded 1 1.99 rounded 2

Astonishing is the result as well: (0.6 / 0.2) asInteger 2

Did you try this code:

{(0.6/0.2)=3. (0.6/0.2)<3. }.

My guessed answer is #(false true)

...

That seems to be the conversion Problem of odd

decimals to binary, well

...

known from most of the programming languages.

Here another experiment: 2.999999999999 asInteger   2 2.999999999999 rounded 3 2.999999999999999 asInteger  2 2.9999999999999999 asInteger 3

Did you try this:

2.9999999999999999 = 3.0

I didn't neither, but my guess is that is will answer true.

...

Is squeak/Smalltalk not x3j20 ansi standard

compliable?

...

Regards

B. Blochl

Obviously, regarding this behavior, Squeak does not happen to be compliant.

Due to inexact behaviour of Float, it seems wiser to me to round rather than truncate, as recommended by the standard (and as illustrated by your very good 0.6/0.2 example).

I don't know what would be the consequences of such a change though...

Nicolas

---

Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners