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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, August 15, 2009 3:28 PM
To: [hidden email]
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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, August 15, 2009 12:18 PM
To: [hidden email]
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 < [hidden email] > 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

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 < [hidden email] > 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 < [hidden email] > 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 < [hidden email] > 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 < [hidden email] > 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 [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> P har [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 < [hidden email] > 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 < [hidden email] > 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 < [hidden email] > 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 < [hidden email] > 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 [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> P har [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes, I know :-|.  Thre is a point where analysis has to finish (== stop pure mathematics) and start the implementation, which bring us back to the constraints of the programming environment.

Otherwise it would prudent to start [to develop] another programming language for that!

Em 15/08/2009 19:06, Igor Stasenko < [hidden email] > escreveu:

2009/8/16 :
> 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 < [hidden email] > 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: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Igor
>> Stasenko
>> Sent: Saturday, August 15, 2009 3:18 PM
>> To: [hidden email]
>> 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,
>> whi ch 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
> &g t; [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-pr [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Wilhelm,

About your point on "benefit a very small number of cases" I paraphase yourself "...is in the code that is not in your image.": if we stick to only our personal experiences and don't think about the future users of the package, we'll arrive at a 'domestic' or 'local' solution which will be useful on another set of not too many number of cases and make Pharo less than an option (for work with this kind of needs) for people that still do not use Pharo.

I see you state your disagreements and do not explain on what grounds so I cannot elaborate, also as it seems the desire of the interested community to go ahead and keep the discussion on the wiki, I'll read what's there and see if is anything else I can contribute.

On a separate thread I'll put on a more general terms my thoughts on the broader theme of use of Smalltalk for more numeric intensive applications and what I think we could improve in Pharo to make easier for programmers that decide the use of this platform.

Em 16/08/2009 00:32, Schwab,Wilhelm K < [hidden email] > escreveu:

Cesar,

Storing integers and fractions for the real and imaginary parts of a complex number will be of benefit in a very small number of cases. Most uses of complex numbers involve transcendental functions that will not produce "nice" results in the general case.

Your closing paragraphs below, well, let's just say I disagree. If you and Ken, separately or together, put proposal(s) on the wiki, I will gladly respond with comments on the pages and/or counter proposal(s), and would be glad to work with Sig on same. As for this seemingly endless chain of email rehashing the same points, I'm done.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, August 15, 2009 9:04 PM
To: Ph [hidden email]
Subject: Re: [Pharo-project] Complex number support discussion

Em 15/08/2009 19:21, Igor Stasenko < [hidden email] > escreveu:

> 2009/8/16 :
> > 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 ].
>
> i'm sure you meant
> length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ]

I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK.

>
> but then
> #positive is a test which defined as
>
> positive
> ^ self > 0
>
> and we getting back to discussion , what is the meaning of #> or #<
> operator for complex values.
>

NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot...

[snipped]

> > 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 mem bers
> > is not a nice design decision...
> >
> ageed. Its can hold any values representing the value from a Real set.
> But as soon as one of its member start holding someting different
> (Complex) - you are in trouble.

It depends. My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized.

This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account.

>
> I simply wanted to illustrate you that passing values to code which
> not expecting the Complex values having same side effect as passing a
> Complex values to members of Complex value (real/imaginary) part, and
> state that its ok.

I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . .

>
> That's why its is good to have separation from functions which
> operating with reals only and can NEVER return anything else than real
> values from functions which can return complex values.

I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming. For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier.

A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing.

The separation you advocate make these advantages be lost.

--
Cesar Rabak


___ ____________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes.  I think most of the discussion has been about 'pure' maths and almost forgotten was the Smalltalk paradigm of dynamic language: ultimately these errors get you to [DM]NUs. . . and you have a debugger window to fix it.


Em 16/08/2009 11:42, Ken.Dickey < [hidden email] > escreveu:

gor Stasenko
> Let me restate where we started from. We started from point:
> Array new: 0.2i

Again, how is this different in pattern from dealing with
Array new: 1/2
Array new: -17
...
??

-KenD

PS:  Complex real: (0.5 + 0i) imaginary: (0 + 0i)
Complex can only have instances of Number as components.  The lack of checks
is an error.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Wilhelm,

About your point on "benefit a very small number of cases" I paraphase yourself "...is in the code that is not in your image.": if we stick to only our personal experiences and don't think about the future users of the package, we'll arrive at a 'domestic' or 'local' solution which will be useful on another set of not too many number of cases and make Pharo less than an option (for work with this kind of needs) for people that still do not use Pharo.

I see you state your disagreements and do not explain on what grounds so I cannot elaborate, also as it seems the desire of the interested community to go ahead and keep the discussion on the wiki, I'll read what's there and see if is anything else I can contribute.

On a separate thread I'll put on a more general terms my thoughts on the broader theme of use of Smalltalk for more numeric intensive applications and what I think we could improve in Pharo to make easier for programmers that decide the use of this platform.

Em 16/08/2009 00:32, Schwab,Wilhelm K < [hidden email] > escreveu:

Cesar,

Storing integers and fractions for the real and imaginary parts of a complex number will be of benefit in a very small number of cases. Most uses of complex numbers involve transcendental functions that will not produce "nice" results in the general case.

Your closing paragraphs below, well, let's just say I disagree. If you and Ken, separately or together, put proposal(s) on the wiki, I will gladly respond with comments on the pages and/or counter proposal(s), and would be glad to work with Sig on same. As for this seemingly endless chain of email rehashing the same points, I'm done.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, August 15, 2009 9:04 PM
To: Ph [hidden email]
Subject: Re: [Pharo-project] Complex number support discussion

Em 15/08/2009 19:21, Igor Stasenko < [hidden email] > escreveu:

> 2009/8/16 :
> > 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 ].
>
> i'm sure you meant
> length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ]

I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK.

>
> but then
> #positive is a test which defined as
>
> positive
> ^ self > 0
>
> and we getting back to discussion , what is the meaning of #> or #<
> operator for complex values.
>

NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot...

[snipped]

> > 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 mem bers
> > is not a nice design decision...
> >
> ageed. Its can hold any values representing the value from a Real set.
> But as soon as one of its member start holding someting different
> (Complex) - you are in trouble.

It depends. My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized.

This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account.

>
> I simply wanted to illustrate you that passing values to code which
> not expecting the Complex values having same side effect as passing a
> Complex values to members of Complex value (real/imaginary) part, and
> state that its ok.

I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . .

>
> That's why its is good to have separation from functions which
> operating with reals only and can NEVER return anything else than real
> values from functions which can return complex values.

I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming. For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier.

A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing.

The separation you advocate make these advantages be lost.

--
Cesar Rabak


___ ____________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project