August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Complex number support discussion

by csrabak＠bol.com.br

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by csrabak＠bol.com.br

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Igor Stasenko

Btw, here is another argument why Complex is not part of Number class hierarchy. Here what reads the Magnitude class: I'm the abstract class Magnitude that provides common protocol for objects that have the ability to be compared along a ___linear dimension___, such as dates or times. Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as Character and LookupKey. --- Since complex values is not scalars and hence cannot be compared along a linear dimension, they could not be inherited from a Magnitude. Btw this comment seems veeery dated, because it refers to ArithmeticValue, which not present in current class hierarchy :) As you stated earlier that Real set is a subset of Complex, then if you want to see both of them lying in same class hierarchy, it could require a major redesign the class hierarchy to make Complex a base class, and Float/Integer a subclasses. Since subclasses are specialization of superclasses, and superclass always is more generic than any of its subclass. Others could step up and say: hey scalars could be seen as a specialized kind of vectors, and vectors could be seen as a specialized kind of matrices, so lets make Matrix to be the ultimate superclass, and then Vector, and then Scalar etc etc.. I can only guess, how far we can go with such generalization(s). -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2009

[Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Schwab,Wilhelm K

Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O. Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. I see a few references to such things in Pharo, but I'm fairly lost. Where should I start reading and/or browsing? Bill

Aug. 15, 2009

Re: [Pharo-project] #< if at first you dont succeed..

by Igor Stasenko

2009/8/15 Ken.Dickey <Ken.Dickey(a)whidbey.com>: > Igor Stasenko <siguctua(a)gmail.com> >> By reading a comment: Â "Not defined on Complex numbers" >> i wonder why implementation is different than following: > ... > > How about this wording: > > "Mathematically, complex numbers are a superset of the real numbers. > Â Complex numbers with a zero imaginary part ARE real numbers and > Â should behave as such. Â That the #< selector is part of the Complex > Â class is an artifact of the current implementation. Â There is no agreed > Â upon model for < comparison for complex numbers in general." > > Better? > Way more better! That will certainly help others (those who not following current discussions) to understand why it is there and why it behaves so. Thanks Ken. > -KenD > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2009

[Pharo-project] #< if at first you dont succeed..

by Ken.Dickey

Igor Stasenko <siguctua(a)gmail.com> > By reading a comment: Â "Not defined on Complex numbers" > i wonder why implementation is different than following: ... How about this wording: "Mathematically, complex numbers are a superset of the real numbers. Complex numbers with a zero imaginary part ARE real numbers and should behave as such. That the #< selector is part of the Complex class is an artifact of the current implementation. There is no agreed upon model for < comparison for complex numbers in general." Better? -KenD

Aug. 15, 2009

Re: [Pharo-project] Create a changeset for an entire package?

by Mariano Martinez Peck

2009/8/15 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > Thanks for all the answers. I used Mariano's way, but I'd like to learn to > do this monticello. > > Stephane, I didn't understand the method you proposed. Anyway, there are > two problems that I need to solve: > > a) I don't wan't to include everything I changed from the package. There > are some things that I changed for debugging. So, I can't fileout everything > and I don't know if monticello will let me do what I want. As far as I know, no, you cannot. That's my I hate MC most. The level of granularity is too big. You cannot commit just code snippets but only a complete package. > > > b) Supose the change includes 3 separate packages, that should be seen as a > one. Loading only one package only would break things, so I'd like the > change to include all 3 in one operation. > > Can this be done? > > > On Fri, Aug 14, 2009 at 7:44 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> save your package with monticello. >> Create a package empty call sliceXXX and add the dirty package as >> dependent (one click button) >> and publish it. >> MC has good supprt for merging. >> >> >> On Aug 14, 2009, at 4:08 PM, Javier PimÃ¡s wrote: >> >> > It seems fixing bugs is not the only hard part... I've a bunch of >> > fixes for GLCanvas, and a small proposed change for the class >> > browser but I can't find a way to export a diff of all the changed >> > packages, nor a diff of an entire package nor a diff of a class so >> > anybody can see the changes before commiting... Do I have to file >> > out every class I changed? there has to some easier way. >> > >> > Thanks, >> > Javier. >> > >> > -- >> > Javier PimÃ¡s >> > Ciudad de Buenos Aires >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 15, 2009

Re: [Pharo-project] Question about MD5

by Mariano Martinez Peck

Ok then...can I commit it in inbox? best, Mariano 2009/8/14 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > Strange, retested now. > With .cs from 1065 also installed I got (first result with what I posted): Time > millisecondsToRun: [500 timesRepeat: [largestByteArray hex]] 23267 32033 > > and without it: > Time millisecondsToRun: [500 timesRepeat: [largestByteArray hex]] > 38877 50751 > > Guess I tested the old version in > an image without 1065 when I wrote the 2x :) > > Cheers, > Henry > > On Aug 14, 2009, at 3:18 58PM, Mariano Martinez Peck wrote: > > > > 2009/8/14 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > >> I added a version to the issue which is almost 2x faster (for large >> ByteArrays at least). I'm not sure if the needs of DBX are such that the >> performance increase can justify the added uglyness (using to:do: instead of >> do: ), but it'd be nice if you would have a look. >> > > Henry: Thanks for your feedback and work! I tried both solutions. The one I > posted, with your benchmark give me 34734. However, with your version, I > have 29675. > > best, > > Mariano > > >> >> Cheers, >> Henry >> >> On Aug 13, 2009, at 3:23 08PM, Mariano Martinez Peck wrote: >> >> Ok. I opened the ticket: >> http://code.google.com/p/pharo/issues/detail?id=1067 >> >> I replaced _ to := and take into considerations the henrik suggestions. >> >> Best, >> >> Mariano >> >> On Thu, Aug 13, 2009 at 9:47 AM, Henrik Johansen < >> henrik.s.johansen(a)veloxit.no> wrote: >> >>> Please also use (String new: (self size * 2)) writeStream instead of >>> '' writeStream. >>> In this case it won't lead to any noticeable performance increases, >>> but it's good practice anyways :) >>> >>> I'd also argue the expected returnvalue of "hex" might not be clear as >>> something like "asHexString" when applied to a collection (hex >>> previously only implemented on single values), but that's a minor issue. >>> >>> When looking around, I also noticed WriteStream nextPut: does an >>> unnecessary check for ByteStrings which is pretty ugly (plus, it >>> decreases nextPut: performance for all ByteString writeStreams), filed >>> as Issue 1065. >>> >>> Cheers, >>> Henry >>> >>> >>> Issue 1065 >>> On Aug 13, 2009, at 10:32 19AM, StÃ©phane Ducasse wrote: >>> >>> > add a nice method comment and a couple of tests! >>> > >>> > Stef >>> > >>> > On Aug 13, 2009, at 1:26 AM, Mariano Martinez Peck wrote: >>> > >>> >> Hi folks: Me and the rest of the team is developing SqueakDBX which >>> >> is a driver to talk with major databases. However, I think the most >>> >> persistence alternatives pharo has, the best. There is no better >>> >> solution for every escenario. So, I am also trying to get the >>> >> PostgreSQL native driver to work in Pharo. This package depends on >>> >> Cryptography because of MD5. I know that there were added to Pharo >>> >> packages like System-Hashing-core, System-Hashing-SHA1 and System- >>> >> Hashing-MD5. However, the driver doesn't work yet. But adding this >>> >> single method: >>> >> >>> >> ByteArray>>hex >>> >> | stream | >>> >> stream _ '' writeStream. >>> >> self do: [ :each | >>> >> stream >>> >> nextPut: ('0123456789ABCDEF' at: each // 16 + 1); >>> >> nextPut: ('0123456789ABCDEF' at: each \\ 16 + 1)]. >>> >> ^ stream contents >>> >> >>> >> The driver works like a charm in Pharo without needing Cryptography >>> >> package. As far as I remember there were no MIT problem with this >>> >> package. Because of this those packages ( System-Hashing-core, >>> >> System-Hashing-SHA1 and System-Hashing-MD5) were integrated in Pharo. >>> >> >>> >> So, can I add it? >>> >> >>> >> Thanks >>> >> >>> >> Mariano >>> >> _______________________________________________ >>> >> Pharo-project mailing list >>> >> Pharo-project(a)lists.gforge.inria.fr >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> > >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > Pharo-project(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> > >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

One programmer's expectation is another's broken code, so "surprise" is not a good standard. Perserving long-standing behavior is. Your multiplication example is esaily handled by double-dispatch, and that would not violate "no implicit coercion" because one of the participants is already complex. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Saturday, August 15, 2009 12:18 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion It helps to undestand your suggestion. It does not help to make it Smalltalk friendly, my meaning of that being the "principle of least surprise". If complex math is to be allowed a natural consequence is that a lot of functions would return complex answers for real arguments. How would then have Pharo Smalltalk behave in a case of computing a reactance: X = jÏL? anInductance being Number and complexFrequency obviously being Complex: aReactance := anInductance * complexFrequency Em 15/08/2009 13:55, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: Nothing tricky: just that methods answering complex results should be defined only by things tha are already complex. -1 sqrt blows up; -1 asComplex answers i. There would be no imlicit conversion between real and complex, allowing the base system to perform as it does now and still allowing all the complex number crunching anyone wants to do. Does that help? Bill

Aug. 15, 2009

Re: [Pharo-project] #< if at first you dont succeed..

by Schwab,Wilhelm K

Ken, Agreed on Nan; I doubt there will be any resistance to making ln signal an error with non-positive arguments. You are taking a bit of a leap to say that any of us have suggested that complex variable theory is not mathematics. A few of have said that restrictions to the reals of various functions are valid and useful. We have already described how to respect that and provide complex numbers at the same time. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ken.Dickey Sent: Saturday, August 15, 2009 11:45 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] #< if at first you dont succeed.. > i disagree. > As i said earlier, a square root function result is not defined for > arguments less than zero in real (R) set. Right, only for complex (C). R < C [C contains R]. > This is strictly mathematical behavior, same as division does not > defines a value for zero. My _Elementary Functions_ book has a nice section which defines the square root of -1 to be 1i. I pick up _Handbook of Physical Calculations_ and find an entire section on the mathematics of alternating current which uses complex math exclusively. I see why, given Smalltalk's history, one does not wish to change the way things are done. This is a bit different from implying complex mathematics is not mathematics. > Just think about, how many code i could break, if i return an Infinity > (or something like this) as a result of division by zero instead of > signaling error. My recollection (again, not to be trusted) is that Java returns an IEEE infinity rather than throwing an exception. I do not recommend this either, which is why I am puzzled by #ln returning a NaN. Again, my recommendation is that the current Complex implementation be removed from Pharo-Core. Reluctant as I am to suggest it, an allowComplexResults global preference could be used, with the usual "Here Be Dragons" warnings. Such a preference would clearly state that it is to allow functions like #ln and #sqrt to return complex results and would only be settable if a Complex number package was loaded. Cheers, -KenD PS: My apologies, but my laptop died and I am borrowing time on someone else's computer. I intent to browse "sqrt senders" when I get another machine to see what code is breaking. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 15, 2009