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 Schwab,Wilhelm K

Certainly complex can have integral values for its real and imaginary parts, but those will be of little use when computing the values of trancendental functions (which is most of what will be done). Sig and I have pointed out that Fraction has a lot more in common with Float than does Complex. This converation needs to move to the wiki in the form of proposals. 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 5:05 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Your first example is interesting. It boils down to two design aspects: If you need Complex numbers in the same application, you need to refactor the code to: length := (something positive) ifTrue:[something sqrt ] IfFalse: Error do: [ 5 ]. array := Array new: length. The application does not complex results at all and through the mechanism Pharo team will decide upon this kind of support will be disabled. About the remaining of discussion, we need to remember all the time Pharo [Smalltalk] is a programming environment that has come concrete in bits at some time in order to become operative (from this onset I think the abusedComplex should trow errors as adequate). The need for Fraction, Float and Integer in most programming languages (Smalltalk included) is more often than not for the sake of efficiency or simplification of the underlying code than for mathematical rigour. So as right as you are that 13/3 returning asFraction does not change the "mathematical meaning of the value" in Smalltalk this is a correct assertion, but in a lot of other environments it is not! They are different representations of numbers that have to be treated as such. In a lot languages I'm versed on, writing 5e100 can only mean an 80 bit float (in most HW) because it is the only way of storing such a beast. In Smalltalk you ask for the class of this and get LargePositiveInteger (Pharo). In Smalltalk 5e100 is syntatic sugar for not having to write one hundred zeros. So, when we decide in certain things in programming language you're making decisions on how to model certain aspects of the problem domain. Smalltalk in the arithmetical part decide to postpone as much as possible the loss of precision of the result. It is an expected behaviour in this language. Once you put Complex in the Smalltalk paradigm, I think we should preserve as much as possible this design decision made at the start of the language. From a programming POV -4 sqrt mapping from Real to Imaginary (Complex) is homologous to 13 / 3 giving a Fraction. Overall is a modeling of the world. BTW, this is why I think having Complex to only have Float members is not a nice design decision... Em 15/08/2009 18:27, Igor Stasenko < siguctua(a)gmail.com > escreveu: 2009/8/15 : > I agree with your first paragraph! However I don't see logical fitting to > example you gave on an Array of 0.2i. . . > because of that: length := [ something sqrt ] on: Error do: [ 5 ]. array := Array new: length. which makes the code which worked before to be badly broken if you change the sqrt behavior to not produce error, when you supply negative value as receiver. Even how ridiculous it may look, some people could deliberately provide the 'wrong' values to functions, expecting them to fail and then to be catched later & handled appropriately. It could serve as a way to simplify the code or workaround. > Again Physics versus Banking, there is lot of physics that is done without > need of complex numbers, and certainly in financial application I cannot > foresee any need to have Complex loaded in an image (except if you need > 'imaginary dollars' in some Ponzi scheme :-D ) > never heard about Ponzi scheme.. :) > About the principle of least surprise (a.k.a. principle of least > astonishment) I thinking about the Smalltalk environment. > > In several programming languages 13 / 3 would return 4. In these languages > this operation is on two integers and integer division gives you four. > > In [Pharo] Smalltalk the result is Fraction. We are used to this. > > So once we have Fraction in the image (OK, just as think experiment. . .), > we can have this automatic promotion of the result. Same happens to the > classic (aNumber factorial) example. > I see where you want to draw a parallel, but this is not the case with Complex. Simply because Fraction is a different represe ntation of values from the same set - Real (or rational) numbers, but its not adds new dimensions and you are not jumping into a complex plane when using fractions. You can potentially pass the Fraction into any function(method) which expects a Real value. But you can't simply pass a Complex value to a function with expects and designed to operate with a Real values, because it would be theoretically/conceptually wrong. Just an example, where you can go conceptually wrong is to write something like: abusedComplex := Complex real: (2i) imaginary: (5i). and then use given value in operations which expecting the complex values and assuming that real & imaginary parts should not be complex in own turn. For the same reason i'm against implicit conversion to complex values as a result of functions which is also defined for real values. > Now. Again in other languages sho uld a programmer want to be sure the result > are less than a truncation she/he coud do: > > 13 / 3.0 or use some of the 'casting' mechanisms available to them. I see > the asComplex need for operations where Complex has been alredy put in > operation as similar to those casts. > You don't need casting with fractions because you don't change the mathematical meaning of the value. But complex values changing it. > Hope it is explicit now. > I hope i clarified my position too :) > Em 15/08/2009 17:36, Igor Stasenko < siguctua(a)gmail.com > escreveu: > > 2009/8/15 : >> Igor, >> >> I think I don't undersand your point. What is the mathematical >> significance >> of an Array of size 0.2i? >> > the significance is not mathematical, it is practical: how many hours > one should s pend fixing all 'surprises' which > you can introduce if not carefully add Complex support. > > Let me remind you that Physics is not the only area where is > mathematcal apparatus is used. > In banking, people using a completely different mathematical > apparatus, and i doubt that they using complex values to calculate > sums on client's accounts. But i don't have any doubts that such > applications require very stable and predictable math functions which > operating mainly over real numbers. > >> Em 15/08/2009 14:35, Igor Stasenko < siguctua(a)gmail.com > escreveu: > & gt; >> 2009/8/15 : >>> 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 retur n 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 >>> Phar o-pr oject(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > P har o-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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ 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] Spelling error in method name

by csrabak＠bol.com.br

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Igor Stasenko

2009/8/16 <csrabak(a)bol.com.br>: > In the context of Complex numbers scalar can be used to call the Real > numbers as complex numbers are homomorphous to 2 dimension vectos see: > http://en.wikipedia.org/wiki/Vector_space. Also a vector space can be > created starting from a complex Field instead of Real one. > > So in this conversation Igor's use of scalar scales well :-) > Yup. But it is unlikely, that in operations where you expecting scalars or some exact kind (real or complex) , you can freely substitute a different kind(s) of scalars - like n-dimention vectors or even matrices and be sure that your code works correctly as before. > Em 15/08/2009 17:49, Igor Stasenko < siguctua(a)gmail.com > escreveu: > > 2009/8/15 Schwab,Wilhelm K : >> Sig, >> >> I don't know in what context you mean "scalars," but complex numbers are >> indeed used as the scalar field for vector spaces. Â That is done both in >> (abstract) algegra and functional analysis - see Hilbert Space. Â That said, >> I see what you mean and generally agree. Â Definitely agreed about the linear >> dimension; complex does not fit in the magnitude hierarchy. > > Yes, the scalar term is a bit ambiguous, so i'd better stop using it. > The wiki gives a disambiguation (http://en.wikipedia.org/wiki/Scalar) > and , by scalar i mean Scalar (computing), which defined as: > > In computing, a scalar is a variable or field that can hold only one > value at a time; as opposed to composite variables like array, list, > record, etc. In some contexts, a scalar value may be understood to be > nume ric. A scalar data type is the type of a scalar variable. For > example, char, int, float, and double are the most common scalar data > types in the C programming language. > > The origin of the term "scalar" in computing dates back to the 1970s, > where the intended meaning was "opposite of vector", so as to > distinguish from the idea of vector processing in computer processor > design. > >> >> We also have to remember that there are pgragmatic aspects to this. Â We >> have been over this several times now, so I think we should table this until >> Ken has time to write up his proposal. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor >> Stasenko >> Sent: Saturday, August 15, 2009 3:18 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Complex number support discussion >> >> 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. >> >> _______________________________________________ >> 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 > &g t; Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2009

[Pharo-project] Monitoring Transcript progress from UI Process

by Chris Muller

Greetings, I am a Pharo newbie. What a nice image! One of the things I'd like to do is monitor the Magma test-suite while it runs; Magma intercepts Notifications from its test suite code to simply Transcript show: them by default. But the Transcript doesn't render them while the UI process is busy, as the following demonstrates: "Screen doesn't update until entire script is complete.." World findATranscript: nil. 1 to: 100 do: [ : n | Transcript cr; show: n; endEntry ] I also tried a World doOneCycleNow but it blows up.. Doesn't seem right anyway.. Thanks, Chris

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 Schwab,Wilhelm K

When I write 2i, I am not really thinking of #i, though one would not doubt end up with that as a way to create complex numbers. To be clear, I have considered and am (currently) opposed to implicit conversions to complex by any elementary or special functions. That propbably reduces to "no" methods of Number and sub-classes answering Complex results. The exceptions would be #asComplex and arithmetic operators. ________________________________ 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 4:29 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Yes, these are the simple to discuss cases as the Number>>i message has been explicitly put. The core of the discussion is the result of certain operations which once complex number support had been switched on should need all the explicit conversions or more application wide (I do agree that system wide flags are to be avoided) suffices to indicate that programmer's desire. Em 15/08/2009 17:38, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: Sorry, I do not follow, but I am saying that 3 * 4i makes every bit as much sense as 2/3 * 4.2 and would be implemented by the same mechanism. The programmer's desire to admit comlex and floating point results, respectfully, is clear from the objects that appear in the calculation. However, spuriously injecting complex numbers into what might be real-only computation will as often as not be unhelpful, and a "surprise." 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 3:28 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion So we have to establish when Number>>i will bring an imaginary (hint [for example]: just when Complex is loaded) or something else due programmer discretion? Or your proposal is that double-dispatch only occur if we have Imaginary new: aNumber? Em 15/08/2009 15:26, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: 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] 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

2009/8/15 <csrabak(a)bol.com.br>: > I agree with your first paragraph! However I don't see logical fitting to > example you gave on an Array of 0.2i. . . > because of that: length := [ something sqrt ] on: Error do: [ 5 ]. array := Array new: length. which makes the code which worked before to be badly broken if you change the sqrt behavior to not produce error, when you supply negative value as receiver. Even how ridiculous it may look, some people could deliberately provide the 'wrong' values to functions, expecting them to fail and then to be catched later & handled appropriately. It could serve as a way to simplify the code or workaround. > Again Physics versus Banking, there is lot of physics that is done without > need of complex numbers, and certainly in financial application I cannot > foresee any need to have Complex loaded in an image (except if you need > 'imaginary dollars' in some Ponzi scheme :-D ) > never heard about Ponzi scheme.. :) > About the principle of least surprise (a.k.a. principle of least > astonishment) I thinking about the Smalltalk environment. > > In several programming languages 13 / 3 would return 4. In these languages > this operation is on two integers and integer division gives you four. > > In [Pharo] Smalltalk the result is Fraction.Â We are used to this. > > So once we have Fraction in the image (OK, just as think experiment. . .), > we can have this automatic promotion of the result.Â Same happens to the > classic (aNumber factorial) example. > I see where you want to draw a parallel, but this is not the case with Complex. Simply because Fraction is a different representation of values from the same set - Real (or rational) numbers, but its not adds new dimensions and you are not jumping into a complex plane when using fractions. You can potentially pass the Fraction into any function(method) which expects a Real value. But you can't simply pass a Complex value to a function with expects and designed to operate with a Real values, because it would be theoretically/conceptually wrong. Just an example, where you can go conceptually wrong is to write something like: abusedComplex := Complex real: (2i) imaginary: (5i). and then use given value in operations which expecting the complex values and assuming that real & imaginary parts should not be complex in own turn. For the same reason i'm against implicit conversion to complex values as a result of functions which is also defined for real values. > Now. Again in other languages should a programmer want to be sure the result > are less than a truncation she/he coud do: > > 13 / 3.0 or use some of the 'casting' mechanisms available to them. I see > the asComplex need for operations where Complex has been alredy put in > operation as similar to those casts. > You don't need casting with fractions because you don't change the mathematical meaning of the value. But complex values changing it. > Hope it is explicit now. > I hope i clarified my position too :) > Em 15/08/2009 17:36, Igor Stasenko < siguctua(a)gmail.com > escreveu: > > 2009/8/15 : >> Igor, >> >> I think I don't undersand your point. What is the mathematical >> significance >> of an Array of size 0.2i? >> > the significance is not mathematical, it is practical: how many hours > one should spend fixing all 'surprises' which > you can introduce if not carefully add Complex support. > > Let me remind you that Physics is not the only area where is > mathematcal apparatus is used. > In banking, people using a completely different mathematical > apparatus, and i doubt that they using complex values to calculate > sums on client's accounts. But i don't have any doubts that such > applications require very stable and predictable math functions which > operating mainly over real numbers. > >> Em 15/08/2009 14:35, Igor Stasenko < siguctua(a)gmail.com > escreveu: > & gt; >> 2009/8/15 : >>> 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 >>&gt ; functions would retur n 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-pr oject(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Phar o-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 > -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2009