[BUG][FIX] FloatArrayIsZero ([er][et][sm] Needs a TestCase)

Frank Shearar frank.shearar at rnid.org.uk
Fri Apr 2 15:50:58 UTC 2004


> >>> "Alexander Lazarevic" 04/02/04 16:21 >>>
>
> Hi Frank!
>
> I did not change any semantics. With some recent update the
> expression =
> 0 was replaced by isZero in some places. Because isZero was missing in
> FloatArray the DNU error showed up when dividing a float by a
> FloatArray.
> A division, which has a FloatArray as dividend or divisor, is defined
> symmetrically, so with my example
>
> 2.0 / (1 2) = (1 2) / 2.0 = (0.5 1.0)		(1)

Ah OK. I find that surprising.

But then your changeset does the right thing, and the only improvement I can
suggest is writing a FloatArrayTest with your changeset-preamble-test string
illustrating the problem/solution. And maybe a #testIsZero too.

> is true. This is just the way it is defined and what made sense to the
> author of that class. You can do a kind of arithmetic with
> Collections,
> too. See Class Collections in the category arithmetic.
> Another thing is,
> that 1 + 4 * 3 = 15 contains only Magnitudes (Integers) and is true in
> Smalltalk (because of the definition of * and + in
> Smalltalk), but does
> not make a mathematical sense to most people.

True. I don't find it bizarre. Any more, that is, since I now understand the
parsing/binding rules :)

> The only problem with isZero in FloatArray that I can see is that it
> _always_ will return false. This is no problem regarding division
> because this a valid operation
>
> 1.0 / #(0.0 0.0) asFloatArray	-->	#(0.0 0.0)
>
> But this could be a surprise
>
> #(0.0 0.0) asFloatArray isZero	-->	false

Yes. That's what lead me to think your changeset was all messed up,
conceptually speaking. But as you point out, you're actually preserving
(restoring, rather) the original intent of the code, which is a Good
Thing(tm)

frank





More information about the Squeak-dev mailing list