Installing Scamper into the latest 3.7alpha from SqueakMap will fail because of the following. (The bug is not in scamper, but that's how I found the bug)
"Change Set: FloatArrayIsZero Date: 2 April 2004 Author: Alexander@Lazarevic.de
Division with FloatArrays will fail because of a missing isZero method. This just adds this method to the class FloatArray.
Testcase :) 2.0 / #(1 2) asFloatArray "
"Alexander@Lazarevic.de" 04/02/04 09:18 >>>
Installing Scamper into the latest 3.7alpha from SqueakMap will fail because of the following. (The bug is not in scamper, but that's how I found the bug)
"Change Set: FloatArrayIsZero Date: 2 April 2004 Author: Alexander@Lazarevic.de
Division with FloatArrays will fail because of a missing isZero method. This just adds this method to the class FloatArray.
Testcase :) 2.0 / #(1 2) asFloatArray "
I'm assuming you expect a FloatArray containing 2.0 and 1.0 from your sample expression, right? That is, "return a FloatArray containing the result of dividing 2.0 by the elements of #(1 2)".
At first I thought your change perfectly reasonable. But what does #isZero actually mean for an array? I mean, we can talk about the zero vector, sure, but a FloatArray (or ByteArray or IntegerArray) can't be zero because it's not a magnitude - it's a collection.
Too, "2.0 / #(1 0) asFloatArray" won't raise a DivideByZero error (as it should (by my interpretation of your test case)).
If you're thinking of a FloatArray as a vector (in the mathematical sense) you can happily talk of "#(1 2) asFloatArray / 2" - that's part of what makes something a vector space. But dividing a scalar by a vector makes no sense in a vector space.
frank
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)
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.
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
Alex
------------------------------------------------------------------------ -
(1) This is an abbreviation of
((2.0 / #(1 2) asFloatArray) = (#(1 2) asFloatArray / 2.0)) = ((2.0 / #(1 2) asFloatArray) = #(0.5 1.0) asFloatArray) = ((#(1 2) asFloatArray / 2.0) = #(0.5 1.0) asFloatArray)
-----Ursprüngliche Nachricht----- Von: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] Im Auftrag von Frank Shearar Gesendet: Freitag, 2. April 2004 13:47 An: 'The general-purpose Squeak developers list' Betreff: RE: [BUG][FIX] FloatArrayIsZero
"Alexander@Lazarevic.de" 04/02/04 09:18 >>>
Installing Scamper into the latest 3.7alpha from SqueakMap will fail because of the following. (The bug is not in scamper, but that's how I
found the bug)
"Change Set: FloatArrayIsZero Date: 2 April 2004 Author: Alexander@Lazarevic.de
Division with FloatArrays will fail because of a missing isZero method. This just adds this method to the class FloatArray.
Testcase :) 2.0 / #(1 2) asFloatArray "
I'm assuming you expect a FloatArray containing 2.0 and 1.0 from your sample expression, right? That is, "return a FloatArray containing the result of dividing 2.0 by the elements of #(1 2)".
At first I thought your change perfectly reasonable. But what does #isZero actually mean for an array? I mean, we can talk about the zero vector, sure, but a FloatArray (or ByteArray or IntegerArray) can't be zero because it's not a magnitude - it's a collection.
Too, "2.0 / #(1 0) asFloatArray" won't raise a DivideByZero error (as it should (by my interpretation of your test case)).
If you're thinking of a FloatArray as a vector (in the mathematical sense) you can happily talk of "#(1 2) asFloatArray / 2" - that's part of what makes something a vector space. But dividing a scalar by a vector makes no sense in a vector space.
frank
"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
squeak-dev@lists.squeakfoundation.org
-
Alexander Lazarevic -
Alexander＠Lazarevic.de
-
Frank Shearar