Squeak-dev November 1999

squeak-dev@lists.squeakfoundation.org

164 participants
545 discussions

Re: Intervals
by Michael Donegan 30 Nov '99

30 Nov '99

Here is a somewhat simpler version of valuesInclude: which is based on the actual construction of the interval. valuesInclude: aNumber "Private - answer whether or not aNumber is one of the enumerated values in this interval." | val | val _ aNumber - self first / self increment. ^ ( val - val rounded ) abs < 1e-10

1 0

RE: need help with a link
by Norton, Chris 30 Nov '99

30 Nov '99

Hi Jason. Bummer on the HD. I think this is what you're after... http://swiki.gsug.org:8080/SQFIXES/ ---==> Chris > -----Original Message----- > From: Jason McVay [SMTP:jmcvay@ipa.net] > Sent: Tuesday, November 30, 1999 10:48 AM > To: squeak > Subject: need help with a link > > howdy all-- > > my HD crashed and i lost all my bookmarks. can anyone give me the address > of > the page that catalogs all the enhancements and fixes that are braodcast > on > this list? > > thanks, > jason

1 0

RE: Intervals
by Lex Spoon 30 Nov '99

30 Nov '99

Michael Donegan <invader(a)zilker.net> wrote: > >Aren't floats fun! :-) > > > > No kidding. The introduction of floats causes a problem because there is no > unified notion of float comparison in Smalltalk. We might decide, e.g. to > use the closeTo: method to determine whether values were in the interval. > But, that wouldn't always work as Dave shows. It is clear that at least one > author assumed that Intervals had integer values only (see the source for > setFrom:to:by:). The only general solution would be to include the fuzz or > epsilon value with an instance and defaulting it to some class variable. > But there are other instances of comparison (like closeTo: and maybe > others) that would not be helped by this solution. > Comparing floats for equality is usually pointless. That considered, why don't we just use exact equality when testing for inclusion, and let people who want some sort of fuzzy match define their own match. The only trick is to make sure that includes: uses the same calculations as do: does; it would be nice for the following to always return all trues: anInterval collect: [ :x | anInterval includes: x ] Lex

1 0

[BUG] Freecell
by Andrew C. Greenberg 30 Nov '99

30 Nov '99

I repeatedly find myself in positions where I attempt to pick up a stack of cards in proper order, but am unable to do so (only the card I clicked appears, and the stack cannot be moved). This most commonly happens when the shuffle coincidentally lays the cards in proper stacking order, but also seems to occur when I move a stack onto a card, and then try to lift the "new" stack to another place. Am I missing something?

4 3

need help with a link
by Jason McVay 30 Nov '99

30 Nov '99

howdy all-- my HD crashed and i lost all my bookmarks. can anyone give me the address of the page that catalogs all the enhancements and fixes that are braodcast on this list? thanks, jason

1 0

Re: [ENH??? Oops] Re: Weak references
by Henrik Gedenryd 30 Nov '99

30 Nov '99

--MS_Mac_OE_3026820810_1247337_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit OK, An added feature ;) If you want it to actually work instead of breaking things, you have to execute a method that converts the existing DependetsFields dictionary to the new format: Object makeDependentsWeak I have placed this in the postscript to the new version of the changeset. Now I'm actually going to wait a little while before posting this, to see if there's anything else. Oh wait, I found something... Never do collect: or select: into a WeakArray, because the contents may disappear very quickly! The issue is #species, which with the current dependents implementation must be non-weak sometimes and weak sometimes. The current solution is therefore not very pretty. But hopefully it works better now. The bottom line is, forget the first change set and use this one. Henrik (fingers crossed) --MS_Mac_OE_3026820810_1247337_MIME_Part Content-Type: text/plain; name="Weak dependents.8.cs" ; x-mac-type="54455854" ; x-mac-creator="522A6368" Content-Disposition: attachment; filename="Weak dependents.8.cs" Content-Transfer-Encoding: imap_stub 0,1820,2,12076,164, --MS_Mac_OE_3026820810_1247337_MIME_Part--

1 0

RE: Intervals
by Jarvis, Robert P. 30 Nov '99

30 Nov '99

> -----Original Message----- > From: David N. Smith (IBM) [SMTP:dnsmith@watson.ibm.com] > Sent: Monday, November 29, 1999 6:42 PM > To: squeak(a)cs.uiuc.edu > Subject: RE: Intervals > > At 13:14 -0500 11/29/99, Jarvis, Robert P. wrote: > >The attached change set combines Andrew's changes with Dan's suggestions > and > >runs correctly for the test cases identified, as well as for negative > >numbers, i.e. > > Hummmm... I've been looking at the code and I wonder if it will > always work with floating point values? Stepping through the interval > involves adding the step value at each increment, but asking if a > value is in the interval involves modulo arithmetic. The problem > comes when the step value cannot be exactly represented in binary > (0.7 for example). > > I can't believe it will always work identically, but I've not been > able to come up with a test case that fails. (I implemented a version > if #includes: that is simply: > > includesP: aValue > ^ self asArray includes: aValue > > and used it for comparison. This IS a precise and accurate solution, > though it might run out of memory at inconvenient times and otherwise > misbehave when the interval has lots of elements. > Using the changes I just (re)posted I find that (1.0 to: 20.0 by: 0.2) includes: 1.2 answers false, where it should answer true. Herewith is the changed change set which adds a fudge factor to dodge around the problems with Float step values. 'From Squeak2.6 of 11 October 1999 [latest update: #1559] on 30 November 1999 at 8:58:03 am'! !Interval methodsFor: 'accessing' stamp: 'rpj 11/30/1999 08:55'! includes: aNumber "Determine if aNumber is an element of this interval. Include a fudge factor to account for Float step values." ^(self rangeIncludes: aNumber) and: [ aNumber - self first \\ step = 0 or: [ (aNumber - self first \\ step - step) abs < 0.000000000000001 ] ]! ! !Interval methodsFor: 'accessing' stamp: 'rpj 11/29/1999 11:39'! rangeIncludes: aNumber ^aNumber between: (self first min: self last) and: (self first max: self last)! ! Bob Jarvis Compuware @ Timken

1 0

RE: Intervals
by Jarvis, Robert P. 30 Nov '99

30 Nov '99

> -----Original Message----- > From: David N. Smith (IBM) [SMTP:dnsmith@watson.ibm.com] > Sent: Monday, November 29, 1999 5:12 PM > To: squeak(a)cs.uiuc.edu > Subject: RE: Intervals > > At 13:14 -0500 11/29/99, Jarvis, Robert P. wrote: > >The attached change set combines Andrew's changes with Dan's suggestions > and > >runs correctly for the test cases identified, as well as for negative > >numbers, i.e. ...SNIP... > > Shouldn't that test on step compare it with ZERO? It fails miserably > when the step is 0.5. > <snip!> <grunt> &*@(*#~! Microsoft products... <grumble> Outlook, in its infinite perversity/wisdom, decided to include my change set at the very end of a message with a lot of quoted material (my own bad habits surfacing), in spite of the fact that it showed up in the more-or-less correct place when I was composing the message. Anyway, here it is again, in raw text form: 'From Squeak2.6 of 11 October 1999 [latest update: #1559] on 29 November 1999 at 12:52:16 pm'! !Interval methodsFor: 'accessing' stamp: 'rpj 11/29/1999 11:46'! includes: aNumber ^(self rangeIncludes: aNumber) and: [ aNumber - self first \\ step = 0 ]! ! !Interval methodsFor: 'accessing' stamp: 'rpj 11/29/1999 11:39'! rangeIncludes: aNumber ^aNumber between: (self first min: self last) and: (self first max: self last)! ! Bob Jarvis Compuware @ Timken

1 0

RE: Shouldn't 2 hash = 2.0 hash? [LONG]
by agree＠carltonfields.com 30 Nov '99

30 Nov '99

This is an excellent discussion. It suggests to me that the blue book notion of "="/hash and "==" do not properly contemplate the more general notion of equality used in computing 2 = 2.0 under the present system. The latter computation is much more than the notion of "represents the same number," which is the Smalltalk/Blue Book notion of "=," but rather is the more general notion of "after coercing both arguments to the same level of generality in a specified hierarchy, represents the same number." I am inclined to argue that David is correct, and that either the "bug" should be tolerated (but hopefully explained), or perhaps less elegantly, that "=" should return false for 2 compared to 2.0, and replaced with a keyword comparison method, say, "numericallyEqual:" which returns true if after proper coercions to a number of appropriate generality, the results are equal. There are even yuckier examples of this, for example, consider: '2' = 2 '2.0' = 2 both of which I can conceive of an application wanting something like "numericallyEqual:' or perhaps "#=" to return true, but for which I would be willing to compromise nothing in determining hash values. The difficulty arises, of course, when you have a class such as Numbers, where most operations are likely to involve coercion of one kind or another to a more general operation. (For this reason, I think Large___Integer hashing must hash consistently with SmallInteger to the extent that overlapping is permitted (or at least that there should be a normalization check in the hash operator). Just out of curiousity, is there any real reason why Floats with integer truncations shouldn't hash to the same value as their integer counterparts? How much slower would that really be? I think that we have at least three layers of equality, and the Blue Book intention is more or less as follows: "==" is the same object (equal oops) "=" represents the same object for purposes of indexing (equal hashes) "purposeEqual:" for other equivalence relationships in an application domain. We are just too well trained to believe that "=" means mathematical equality for numbers, I suppose, but we can get over it in the long run. When faced with a reflexive, transitive and associative relationship, we should take care to consider whether we really want to > -----Original Message----- > From: MIME :dnsmith@watson.ibm.com > Sent: Monday, November 29, 1999 4:34 PM > To: squeak(a)cs.uiuc.edu > Cc: squeak(a)cs.uiuc.edu > Subject: Re: Shouldn't 2 hash = 2.0 hash? [LONG] > > > At 17:33 -0600 11/28/99, R. A. Harmon wrote: > >I found the following: > > > > 2 = 2.0 -> true > > 2 hash = 2.0 hash ->false > > > >I think this is a bug. Is it? > > Good question. The blue book says: > > "... Any two objects that are equal must return the same > value for #hash. Unequal values may or may not return equal > values for hash. Typically, this integer is used as an index > to locate the object in an indexed collection..." > [Pg 96]. > > (I cannot find any reference in the blue book to another > hashing rule: The hash value of an object must be constant > over time. There is yet another hashing rule that is more > practical: Hash values should be small integers.) > > So, by the Blue Book definition, what you observe is a bug. > > > Should it be? Does it really mean that two instances of > wildly differing classes must answer equal hashes when they > compare equal? Why does the Blue Book make this restriction? > > All of the discussion in the Blue Book about hashing is in > the context of looking up values in a hashed collection. Did > they intend that someone might put a float 2.0 into a hashed > collection and then look it up with an integer 2? Do people do it? > > Maybe there is some other reason for this rule, but I think > it might just be incompletely stated. Consider these cases: > > * An employee object compares equal using the employee > number. Should (anEmployee = 899538) answer true or purposely > hash the same? I think the hashes can be safely different. > The two classes are quite separate in intent and use, and the > fact they compare equal is an accident. > > * In another implementation, employee objects are represented > as instances of classes in a hierarchy. Should > aRetiredEmployee compare equal to anActiveEmployee if, by > accident, they have the same employee number? Sure! Should > they have the same hash value? Of course. The classes here > are closely related and should follow the rule. In fact, > making a new employee and then trying to find it in a > dictionary of existing employees would find a nasty bug. > > So, maybe the rule should state something about closely > related objects answering the same hash, but I don't see a > good and simple way to say it. > > Are subclasses of Number closely related enough that they > should follow the rule? > > > Most Smalltalk systems do what you expect. > > In order to keep hash fast, IBM Smalltalk simply truncates > all floats to integers and use the hash of that. It's an ugly > solution, IMHO. That means, for example, that a dictionary > which uses floats as keys may have just a few unique hash > values for a large number of entries; it can end up doing a > sequential search instead of a simple probe with the hash. > > One could make the hash operation more complex, so that any > non-zero fractional part is used in the hash, but then the > hash operation slows down. Many systems do that and have a > slower floating point hash, harmful or not. > > There are similar problems with scaled decimal values. > > So, should the rule be followed even if it's more expensive > to do so? Are subclasses of Number closely related enough > that they should follow the rule regardless? Are the 'same' > values represented as different classes ever used as > equivalent keys in a hashed collection? > > > In my view, and assuming I'm not missing something obvious, > the answer is no. > > I'd argue that having (2.0 = 2) answer false is better than > forcing the hashes to be equal. Besides, comparing floats is > a sin one should not encourage. I'd rather see #= answer > false and that some other method be used for 'has equivalent value'. > > While I did write that floating-point hash method, Squeak > didn't follow the rule before I wrote it, which is why I > didn't make the new version follow it either. > > > But you did ask a good question, and I didn't really answer > it. Anyone have a better answer? > > > Dave > > _______________________________ > David N. Smith > IBM T J Watson Research Center > Hawthorne, NY > _______________________________ > Any opinions or recommendations > herein are those of the author > and not of his employer. > > > >

4 3

Some questions about Squeak
by Stephane Ducasse 30 Nov '99

30 Nov '99

Hi I'm restarting to play with Squeak and I'm really familiar with the mailing-list so here is a list of questions I have: **I would like to know if there is a way to propose new improvements for the smalltalk kernel. For example: it could be really good to have an automatic initialization protocol like in Clos, to avoid to have to define everywhere this boring new ^ super new initialize in CLOS the make-instance method is calling the initialize-instance for ALL the objects in the system. In Smalltalk, we would just have to redefine Behavior>>new to call Object>>initialize. We could let basicNew for emergency purpose. **I tried several times to get automatic update from the server but I NEVER succeeded. Is there somethign wrong? **The mailing list is quite buzy. Is there no plans to have a newgroup? I know that some of you think that Squeak is not ready for the mainstream people but this would help people that are interested to communicate more easily. **Long time ago somebody said that I was starting to port the Refactoring Browser. Is this project still alive? I discussed with John Brant at OOPSLA and he told me that at the refactoring engine level he did not see problems. **I tried Squeak 2.6 on Unix and I got a lot of error linked with the BallonEngine, while on the mac and PC I got no problem at all. ** The uiuc server is often pretty difficult to obtain. Yesterday for the first time I was able to play with the music (just because I never thought before that I could download another midi file). It could be fun to have a small set of midi file on the Squeak ftp site too. Stephane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes University of Bern, Institut fuer informatik and Mathematik IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.

7 9

Jump to page: