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

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

by Javier PimÃ¡s

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. 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

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Igor Stasenko

2009/8/15 <csrabak(a)bol.com.br>: > 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". > least suprise for who? For you it could be the least surprise. For me, and for other people it would be a big surprise. So, please give a better/different reasoning, why in a presence of Complex numbers, a functions which operating with Real numbers should change their behavior. Integers are subset of Real set and Real is a subset of Complex, then one could happily write: Array new: 0.2i and following your reasoning, the above is good way to write a code and it should work well. > 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 > > _______________________________________________ > 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

Re: [Pharo-project] Complex number support discussion

by csrabak＠bol.com.br

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>: >> 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. > Is it hard to understand that we are talking about completely different functions? Both are square root, but one is operator R -> R, while another is operator C -> C (assuming that R is a subset of C). For instance , a matrix algebra also defines a matrix multiplication operator (*), but it behaves completely different from scalar multiplication operator (*), its not symmetic , and there is no reverse operation (division - only partial, for matrices which can be reversed). So, what will happen, if you try to 'unify' both operators to be matrix multiplication? Do you ready to sacrifice the symmetry of scalar multiplication, because matrix multiplication is more generic? > 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. > I don't see how it can be related to Smalltalk history. I learnt math more than a 15 years ago, including complex numbers and i remember the distinction between functions which operating strictly in real set, and ones which operating over complex plane, and difference between them. They are not same! >> 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 > -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2009

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

by csrabak＠bol.com.br

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

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 ________________________________ 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 11:08 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion I do agree on your gripe about the globality (in the first proposal of mine I mentioned that), but I don't grasp in fully the "separated world concept". Could you elaborate? Em 14/08/2009 21:42, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: I really do not like the flag idea, because it is global. What if there are two phases to something, one that uses complex numbers, and one that does not? Since the complex numbers are the far less likely be needed and much newer feature to Smalltalk, the separate world design will be the cleaner and better accepted option. Bill ________________________________ 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: Friday, August 14, 2009 7:16 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion That's why I suggest (once Complex be loaded) a flag something like Smalltalk complexResultsOn and its counterpart to turn off be used instead. Em 14/08/2009 20:53, John McIntosh < johnmci(a)smalltalkconsulting.com > escreveu: Yes but we usually don't do explicit casting Like 2 asFloat * 3.0 We could but where does the implicit type conversion lie? On 8/14/09, Schwab,Wilhelm K wrote: > John, > > If I may be so presumptuous, the answer is to have people use #asComplex > when they want complex results. -2 sqrt throws an error; -2 asComplex sqrt > gives the complex (imaginary) result. Then we break no old code, we offer > useful new features with minimal effort required to invoke them. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M > McIntosh > Sent: Friday, August 14, 2009 4:55 PM > To: Pharo-project(a)lists.gforge.inria .fr > Subject: Re: [Pharo-project] Complex number support discussion > > > On 14-Aug-09, at 1:04 PM, Schwab,Wilhelm K wrote: > >> John, >> >> That is not far from the eveolving conscensous opinion - I think we >> can indeed claim to have a collective desire to leave integers and >> floats as they are. One concern I have about your suggestion is what >> happens when the user loads the complex package? Does existing code >> break? It would given Ken's proposal. There are alternatives, and >> they are discussed in this fairly extensive thread. >> >> Besides, someone wanting complex numbers will look for and load a >> package to support them, as long as it is good code. Complex is fine >> as far as it goes; some FFI magic to benefit from GSL functionality >> would be nice. We should also have an analog to FloatArray that has >> complex entries; again, a wrapper onto GSL would be a nice addition. >> >> I have no power over Ken; he can build what he wants. I would like to >> see his energy directed toward creating something we can all use. I >> suggest a layered proposal on the wiki and up or down votes on what >> becomes part of Pharo. If the vote(s) split, we have benevolent >> dictators to sort it out. >> >> Bill > > Ah, yes well I think I lost the 0.2 = (1/2) argument, so anything goes. > > I think the choice is either numbers + complex work as expected, or you just > offer number then offer to load the complex logic as soon as someone wants > -2 sqrt. > > Obviously the problem here is that for a vast r ange of programmers if you > offer up -2 sqrt by default and it does not throw an excepti on they will be > confused. Some of them likely have NO idea what a complex number is. > > Random thoughts. > > No-doubt there are abuses of math to string where people assume you have an > integer like thing versus a complex number string. > > > -- > = > = > = > ======================================================================== > John M. McIntosh Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list & gt; Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- =========================================================================== John M. McIntosh Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ 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

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

by Ken.Dickey

> 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.

Aug. 15, 2009

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

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] ORM for Pharo -- Â½ OFF

by csrabak＠bol.com.br

Aug. 15, 2009