#< if at first you dont succeed..

OK, here is a strict version.  Complex>>< only compares numbers on the real or
imaginal axis and throws an "incomparable" error otherwise.  The
ComplexTest>>textCompare checks obvious cases.

Is this version (more) acceptable?

As usual, please feel free to correct (or send me corrections) for better
coding style (e.g a shorter/better error message) as well as any dumbness on
my part.

Cheers,
-KenD
------------------------Complex
< other
        "Can only compare with pure real or imaginary parts"
        ((self imaginary = 0) and: [other imaginary = 0])
        ifTrue: [^ self real < other real]
        ifFalse: [((self real = 0) and: [other real = 0])
                ifTrue: [^self imaginary < other imaginary]
                ifFalse: [ArithmeticError new
                        signal: 'Complex numbers are not generally comparable'.]
                ]
------------------------

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

For the mathematical part yes. Now, submiting to all the list, I want to propose a modification in the code based on Smalltalk style (the comments w/"csr" are only for my explanation and should not go to the production code!):

< other
"Can only compare with pure real or imaginary parts"
((self imaginary = 0) and: [other imaginary = 0])
ifTrue: [^ self real < other real].               "csr: if it's true you returned, so no need the iFalse part"
((self real = 0) and: [other real = 0])
ifTrue: [^self imaginary < other imaginary]. "csr: same here"
ArithmeticError new signal: 'Complex numbers are not generally comparable' "csr: Only will happen if no one of the above blocks returned"

HTH

Em 12/08/2009 21:39, Ken.Dickey < [hidden email] > escreveu:

OK, here is a strict version. Complex>>< only compares numbers on the real or
imaginal axis and throws an "incomparable" error otherwise. The
ComplexTest>>textCompare checks obvious cases.

Is this version (more) acceptable?

As usual, please feel free to correct (or send me corrections) for better
coding style (e.g a shorter/better error message) as well as any dumbness on
my part.

Cheers,
-KenD
------------------------Complex
< other
"Can only compare with pure real or imaginary parts"
((self imaginary = 0) and: [other imaginary = 0])
ifTrue: [^ self real < other real]
ifFalse: [((self real = 0) and: [other real = 0])
ifTrue: [^self imaginary < other imaginary]
ifFalse: [ArithmeticError new
signal: 'Complex numbers are not generally co mparable'.]
]
------------------------

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

2009/8/13  <[hidden email]>:
> For the mathematical part yes. Now, submiting to all the list, I want to
> propose a modification in the code based on Smalltalk style (the comments
> w/"csr" are only for my explanation and should not go to the production
> code!):
>
> < other
> "Can only compare with pure real or imaginary parts"
> ((self imaginary = 0) and: [other imaginary = 0])
> ifTrue: [^ self real < other real].               "csr: if it's true you

i think, if imaginary part is zero , then Complex values should be
normalized back to real ones (obviously to conserve the memory), and
therefore the test 'self imaginary = 0' is redundant.

> returned, so no need the iFalse part"
> ((self real = 0) and: [other real = 0])
> ifTrue: [^self imaginary < other imaginary]. "csr: same here"
> ArithmeticError new signal: 'Complex numbers are not generally comparable'
> "csr: Only will happen if no one of the above blocks returned"
>

But back to the question:
in given form, i really don't see what is the meaning of #< operator
on Complex numbers?
Because , obviously, in first place, i expecting that #< method serves
to compare Complex numbers, not mix of real and complex,
but implemented in such form, the value of such method is nearly zero
(in complex plane ;).
So, the question remains the same: is it worth adding it, just for the
sake of complete protocol(s)?

P.S. diving into complex plane uncovers many potential pitfalls to
those who expecting a certain behavior of mathematical functions over
a real numbers.
In first place square and square root.
It is good that with introduction of a complex numbers we can be sure that
x sqrt squared = x
for any real x.

The complex numbers gives us a impression that from now on, the square
function and squared root functions is reversable.
But they are not for a complex numbers.
In practice this means, that one, who using a complex math in his
code, should know well the properties of complex numbers, because this
is not so trivial as with real numbers & school algebra. And such
people, basically don't need the things with questionable or
controversial behavior such as #< operators on a complex plane.
Then the aim of Complex package developer should be to not introduce
more confusion to people who is not using/learnt the complex numbers,
and leave attempts to help people who can - because they could care
for themselves well.




--
Best regards,
Igor Stasenko AKA sig.

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

Ken,

At least it is non-ambiguous from a mathematical perspective, though I am still curious why this is so important to you - there might be a better solution to your problem.  I would replace #= with #closeTo:.  Float>>= runs through #asTrueFraction, which yields a rational but can still miss.

Speaking of #closeTo:, the tolerances look a little wide to me at first glance; it deserves a careful look.


Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey
Sent: Wednesday, August 12, 2009 7:40 PM
To: [hidden email]
Subject: [Pharo-project] #< if at first you dont succeed..

OK, here is a strict version.  Complex>>< only compares numbers on the real or imaginal axis and throws an "incomparable" error otherwise.  The
ComplexTest>>textCompare checks obvious cases.

Is this version (more) acceptable?

As usual, please feel free to correct (or send me corrections) for better
coding style (e.g a shorter/better error message) as well as any dumbness on
my part.

Cheers,
-KenD
------------------------Complex
< other
        "Can only compare with pure real or imaginary parts"
        ((self imaginary = 0) and: [other imaginary = 0])
        ifTrue: [^ self real < other real]
        ifFalse: [((self real = 0) and: [other real = 0])
                ifTrue: [^self imaginary < other imaginary]
                ifFalse: [ArithmeticError new
                        signal: 'Complex numbers are not generally comparable'.]
                ]
------------------------

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

+1



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Wednesday, August 12, 2009 9:06 PM
To: [hidden email]
Subject: Re: [Pharo-project] #< if at first you dont succeed..

2009/8/13  <[hidden email]>:
i think, if imaginary part is zero , then Complex values should be normalized back to real ones (obviously to conserve the memory), and therefore the test 'self imaginary = 0' is redundant.

> returned, so no need the iFalse part"
> ((self real = 0) and: [other real = 0])
> ifTrue: [^self imaginary < other imaginary]. "csr: same here"
> ArithmeticError new signal: 'Complex numbers are not generally comparable'
> "csr: Only will happen if no one of the above blocks returned"
>

But back to the question:
in given form, i really don't see what is the meaning of #< operator on Complex numbers?
Because , obviously, in first place, i expecting that #< method serves to compare Complex numbers, not mix of real and complex, but implemented in such form, the value of such method is nearly zero (in complex plane ;).
So, the question remains the same: is it worth adding it, just for the sake of complete protocol(s)?

P.S. diving into complex plane uncovers many potential pitfalls to those who expecting a certain behavior of mathematical functions over a real numbers.
In first place square and square root.
It is good that with introduction of a complex numbers we can be sure that x sqrt squared = x for any real x.

The complex numbers gives us a impression that from now on, the square function and squared root functions is reversable.
But they are not for a complex numbers.
In practice this means, that one, who using a complex math in his code, should know well the properties of complex numbers, because this is not so trivial as with real numbers & school algebra. And such people, basically don't need the things with questionable or controversial behavior such as #< operators on a complex plane.
Then the aim of Complex package developer should be to not introduce more confusion to people who is not using/learnt the complex numbers, and leave attempts to help people who can - because they could care for themselves well.




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

Igor Stasenko
> in given form, i really don't see what is the meaning of #< operator on
> Complex numbers? Because , obviously, in first place, i expecting that #<
> method serves to compare Complex numbers, not mix of real and complex, but
> implemented in such form, the value of such method is nearly zero (in
> complex plane ;). So, the question remains the same: is it worth adding it,
> just for the sake of complete protocol(s)?

How much is "if A=a and B=b and A<B then a<b" worth to you?

-KenD

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

2009/8/13 Igor Stasenko <[hidden email]>:
Hi Igor,
this is Behavior of Complex package available in VW.
However, I wonder how you can conciliate the previous requirement:
-2 asComplex sqrt

For example, I want this function
myFun
^x sqrt arcSin
But I know -4 myFun will fail...

So, I hear you and write
myFun
^x asComplex sqrt arcSin
But there, problem, 4 myFun will raise an error, so as 4 asComplex myFun

Then, i can write smelling code like this - that's no real fun ;)
myFun
^x asComplex sqrt asComplex arcSin

unless of course you propose I hide this shit behind some other selectors like:
myFun
^x complexSqrt complexArcSin

but then I will probably want some other extensions like the
quaternionArcSin, the squareMatrixArcSin, etc...
so, I don't know if I'm really satisfied with those selectors...

Nicolas

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

Ken,

How does your reasoning follow if we cannot compare A with B if they be Complex?

Em 13/08/2009 13:38, Ken.Dickey < [hidden email] > escreveu:

Igor Stasenko
> in given form, i really don't see what is the meaning of #< operator on
> Complex numbers? Because , obviously, in first place, i expecting that #<
> method serves to compare Complex numbers, not mix of real and complex, but
> implemented in such form, the value of such method is nearly zero (in
> complex plane ;). So, the question remains the same: is it worth adding it,
> just for the sake of complete protocol(s)?

How much is "if A=a and B=b and A

-KenD

_______________________________________________
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

2009/8/14 Nicolas Cellier <[hidden email]>:
You are right about drawbacks of normalization.
I suggested that by taking Ken's implication, that any real number is
a complex number with imaginary part = 0.

I'm not very satisfied with selectors , like arcSin/complexArcSin too,
but is there other way to put two different functions into a single
class (Float) - without assigning different selectors to them?
I hope you agree with me that arcSin and complexArcSin is two
different functions with different behavior , as well as
sqrt and complexSqrt.
They could be the same (with complex behavior) , if we imply that real
numbers is a complex numbers with imaginary part =0. But once we
assume that , we automatically losing the set of functions which
defined strictly over a real set and which should throw an error(s) if
argument is not in valid range.
And i'm not in favor of losing that.

> Nicolas
>
> _______________________________________________
> 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

Treating reals as complex (giving them a zero imaginary part) is a bad idea.  Reasons include:

(1) need float and double for FFI
(2) compatibility with other dialects
(3) avoid wasting space to hold unneeded imaginary parts

Sig is correct to point out that sometimes one wants to do purely real arithmetic with the domains of various functions restricted as appropriate.  Complex numbers should be separate from reals.




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Thursday, August 13, 2009 6:07 PM
To: [hidden email]
Subject: Re: [Pharo-project] #< if at first you dont succeed..

2009/8/14 Nicolas Cellier <[hidden email]>:
You are right about drawbacks of normalization.
I suggested that by taking Ken's implication, that any real number is a complex number with imaginary part = 0.

I'm not very satisfied with selectors , like arcSin/complexArcSin too, but is there other way to put two different functions into a single class (Float) - without assigning different selectors to them?
I hope you agree with me that arcSin and complexArcSin is two different functions with different behavior , as well as sqrt and complexSqrt.
They could be the same (with complex behavior) , if we imply that real numbers is a complex numbers with imaginary part =0. But once we assume that , we automatically losing the set of functions which defined strictly over a real set and which should throw an error(s) if argument is not in valid range.
And i'm not in favor of losing that.

> Nicolas
>
> _______________________________________________
> 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
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/8/14 Igor Stasenko <[hidden email]>:
Agree, from pragmatic POV, it's better to not break a majority of existing code
Complex is unused in base image, and most #sqrt senders wouldn't know
how to deal with a damn imaginary result.
I have no solution for this simple annoying thing.
Installing error handlers to deal with complex extension is quite boring too...

Regarding quality of design decisions, Matlab is far from being my top
choice (definition of < for complex would be a grief quite related to
this thread...), but I note the existence of mexp msin etc... (exp
would collect the exponential of each matrix element)... It's good to
know we are not the only ones annoyed, so yes, we could tolerate these
unsatisfying selector variations.

Mathematical expressions are context dependent (idealy notations are
defined in preamble).
Translated in Smalltalk world, that would mean MethodDictionary would
be Context dependent...
But I should better stop here, I can feel like a burning smell coming
from my neurons.

Nicolas

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

Nicolas,

If I'm following you on the matlab matrix exponential business, we should be able to handle such things polymorphically: exp sent to a matrix would do the right thing for a matrix, just as Float and Complex would respond appropriately.  The sticking point here is whether operations on floats should produce complex numbers in place of bounds errors; based on the arguments presented over the past few days, I vote no.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nicolas Cellier
Sent: Thursday, August 13, 2009 6:46 PM
To: [hidden email]
Subject: Re: [Pharo-project] #< if at first you dont succeed..

2009/8/14 Igor Stasenko <[hidden email]>:
Agree, from pragmatic POV, it's better to not break a majority of existing code Complex is unused in base image, and most #sqrt senders wouldn't know how to deal with a damn imaginary result.
I have no solution for this simple annoying thing.
Installing error handlers to deal with complex extension is quite boring too...

Regarding quality of design decisions, Matlab is far from being my top choice (definition of < for complex would be a grief quite related to this thread...), but I note the existence of mexp msin etc... (exp would collect the exponential of each matrix element)... It's good to know we are not the only ones annoyed, so yes, we could tolerate these unsatisfying selector variations.

Mathematical expressions are context dependent (idealy notations are defined in preamble).
Translated in Smalltalk world, that would mean MethodDictionary would be Context dependent...
But I should better stop here, I can feel like a burning smell coming from my neurons.

Nicolas

_______________________________________________
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

2009/8/14 Schwab,Wilhelm K <[hidden email]>:
> Nicolas,
>
> If I'm following you on the matlab matrix exponential business, we should be able to handle such things polymorphically: exp sent to a matrix would do the right thing for a matrix, just as Float and Complex would respond appropriately.  The sticking point here is whether operations on floats should produce complex numbers in place of bounds errors; based on the arguments presented over the past few days, I vote no.
>
> Bill
>

Agree for pragmatic reasons.
I was just exploring alternatives implied by this no, and #complexSqrt
and the like are one of them.

To summarize, you tell me that if a function f is well defined other a
whole set A, then you encourage it's extension to a superset B with
polymorphism:
f: A -> A
f: B -> B
Problems arise when f is defined only on a subset A* of A, but has an
extension over B:
f: A* -> A
f: A -> B
f: B -> B
First two definitions are ambiguous, and expectations will vary with
applications.
This is the case of #sqrt.
Igor said, very simple, just forget definition #2, keep #1 and #3 and
write -2 asComplex sqrt.

So far so good, and this is in the spirit of Squeak Complex implementation.

But Igor added that in case of this property on a subset B*
f: B* -> A
then it would be better to automatically classify result as member of
A for any element of B*
Answer a Float rather than carrying a Complex with null imaginary part
for example like 4 asComplex sqrt -> 2 rather than 2+0i.
I argue that though the two features are appealling, they are hard to mix.
That's the point that we were discussing, leading us to an ugly
solution like FORTRAN non generic INTRINSIC functions...

Concerning Matlab exp/mexp, ambiguity is between 1-D array (Array
Programming Language/FloatArray like extension) and square matrix
(infinite series expansion). That's a bit different, and the example
was not that well chosen, I confess. Smalltalk implementations are
potentially exposed to the same ambiguity though.

That's longer, I don't know if clearer...

Nicolas

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

Ken,
as Bill already noticed, there might be a difference between an exact
zero (0) and an inexact zero (0.0).
Isn't that difference emphasized in Scheme?
That reminds me
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102247.html
:)

Nicolas

2009/8/13 Ken.Dickey <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I think the whole point is that introducing Complex as an "automatic" solution to  <-Number sqrt > "problem" is just sending of dirt under the rug:

I maintain that there is no reasonable behaviour once we get out of Arithmetic:

4 sqrt should return 2 or 2.0 or #(-2 2)?

Once we have Complex, what should be the result returned by:

27^(1/3)  3, 3.0 or #(3.0 (-1.5 - 2.598i) (-1.5 + 2.598i)??

 

Em 13/08/2009 22:22, Nicolas Cellier < [hidden email] > escreveu:

2009/8/14 Schwab,Wilhelm K :
> Nicolas,
>
> If I'm following you on the matlab matrix exponential business, we should be able to handle such things polymorphically: exp sent to a matrix would do the right thing for a matrix, just as Float and Complex would respond appropriately.  The sticking point here is whether operations on floats should produce complex numbers in place of bounds errors; based on the arguments presented over the past few days, I vote no.
>
> Bill
>

Agree for pragmatic reasons.
I was just exploring alternatives implied by this no, and #complexSqrt
and the like are one of them.

To summarize, you tell me that if a function f is well defined other a
whole set A, then you encourage it's extension to a superset B with
polymorphism:
f: A -> A
f: B -> B
Problems arise when f is defined only on a subset A* of A, but has an
extension over B:
f: A* -> A
f: A -> B
f: B -> B
First two definitions are ambiguous, and expectations will vary with
applications.
This is the case of #sqrt.
Igor said, very simple, just forget definition #2, keep #1 and #3 and
write -2 asComplex sqrt.

So far so good, and this is in the spirit of Squeak Complex implementation.

But Igor added that in case of this property on a subset B*
f: B* -> A
then it would be better to automatically classify result as member of
A for any element of B*
Answer a Float rather than carrying a Complex with null imaginary part
for example like 4 asComplex sqrt -> 2 rather than 2+0i.
I argue that though the two features are appealling, they are hard to mix.
That's the point that we were discussing, leading us to an ugly
solution like FORTRAN non generi c INTRINSIC functions...

Concerning Matlab exp/mexp, ambiguity is between 1-D array (Array
Programming Language/FloatArray like extension) and square matrix
(infinite series expansion). That's a bit different, and the example
was not that well chosen, I confess. Smalltalk implementations are
potentially exposed to the same ambiguity though.

That's longer, I don't know if clearer...

Nicolas

_______________________________________________
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

Nicolas,

I think you might be reading more than I intended into my mention of polymorphism.  It is true that the real-to-complex transition fits as an extension of the domain of a function, but I'm less comfortable doing that with real-to-matrix.  The real line is a subset of the complex plane.  Real numbers can be treated as linear transformations[*] which makes them a 1x1 matrix.  Still, it feels like a stretch to extend that into a higher dimensional space, but I might be missing something.

However, my focus was not on mathematics but on the software aspects of the problem: in a C* world, there are only functions, and putting aside C++'s overloading capabilities, the procedural programmer is "forced" to start with a function, and to use a different name for each argument type.  So they end up with

   normReal(x);
   normMatrix(x);
   etc.

where we can simply do

   x := Float pi.
   x norm.
   x := Matrix vandermonde:5.
   x norm.

and get sensible answers for each via polymorphism.  Does that make sense?

Of course, sometimes a number is just a number, and they can be pretty useful by themselves.  We should not throw them away too easily.  I suspect that any package that breaks floating point computation will be summarily ignored.

Bill



[*] If nothing else, that is the insight behind the Frechet Derivative which rearranges the familiar difference quotient to view the derivative itself as a linear transformation, all the way down to the one-dimensional case.




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Nicolas Cellier
Sent: Thursday, August 13, 2009 8:23 PM
To: [hidden email]
Subject: Re: [Pharo-project] #< if at first you dont succeed..

2009/8/14 Schwab,Wilhelm K <[hidden email]>:
> Nicolas,
>
> If I'm following you on the matlab matrix exponential business, we should be able to handle such things polymorphically: exp sent to a matrix would do the right thing for a matrix, just as Float and Complex would respond appropriately.  The sticking point here is whether operations on floats should produce complex numbers in place of bounds errors; based on the arguments presented over the past few days, I vote no.
>
> Bill
>

Agree for pragmatic reasons.
I was just exploring alternatives implied by this no, and #complexSqrt and the like are one of them.

To summarize, you tell me that if a function f is well defined other a whole set A, then you encourage it's extension to a superset B with
polymorphism:
f: A -> A
f: B -> B
Problems arise when f is defined only on a subset A* of A, but has an extension over B:
f: A* -> A
f: A -> B
f: B -> B
First two definitions are ambiguous, and expectations will vary with applications.
This is the case of #sqrt.
Igor said, very simple, just forget definition #2, keep #1 and #3 and write -2 asComplex sqrt.

So far so good, and this is in the spirit of Squeak Complex implementation.

But Igor added that in case of this property on a subset B*
f: B* -> A
then it would be better to automatically classify result as member of A for any element of B* Answer a Float rather than carrying a Complex with null imaginary part for example like 4 asComplex sqrt -> 2 rather than 2+0i.
I argue that though the two features are appealling, they are hard to mix.
That's the point that we were discussing, leading us to an ugly solution like FORTRAN non generic INTRINSIC functions...

Concerning Matlab exp/mexp, ambiguity is between 1-D array (Array Programming Language/FloatArray like extension) and square matrix (infinite series expansion). That's a bit different, and the example was not that well chosen, I confess. Smalltalk implementations are potentially exposed to the same ambiguity though.

That's longer, I don't know if clearer...

Nicolas

_______________________________________________
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

"Schwab,Wilhelm K" <[hidden email]>
> Treating reals as complex (giving them a zero imaginary part) is a bad
> idea.   Reasons include:
>
> (1) need float and double for FFI
??

> (2) compatibility with other dialects

Squeak and Pharo already have some invompatabilities (e.g. not requiring
#initialize after #new). I do agree that dialect compatibility is a good
thing in general.

> (3) avoid wasting space to hold unneeded imaginary parts

No need for extra space.

Number>>real
  ^self

Number>>imaginary
  ^0

> Sig is correct to point out that sometimes one wants to do purely real
> arithmetic with the domains of various functions restricted as appropriate.
>  Complex numbers should be separate from reals.

I think that this might be approached differently.

Thought experiment.

I have a Smalltalk without negative numbers (How can you take something away
from nothing? Screen pixels start at 0@0 I can't draw pixels off-screen! If I
get "negative" pixels I have to check every pixel calculation to see if I am
on screen or not.).

So now I make a package which supplies NegativeNumbers.

The argument is that this changes the behavior which people rely on (breaks
existing code) and that nobody uses these imaginary negative things anyway.

Should one not allow this package?


Note that again, for consistency, I suggest that making Complex a package
implies removing the current Complex implementation.  If a Complex package
exists, I expect  (-1 sqrt) to give 1i.

My intent is for consistency.  Packages allow for completeness.  Can we both
be happy?

$0.02,
-KenD

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

Ken,

You seem determined to have the behavior of Float change when the complex package is installed, and there  are various objections to that from multiple people; those objections are well founded.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey
Sent: Friday, August 14, 2009 10:38 AM
To: [hidden email]
Subject: Re: [Pharo-project] #< if at first you dont succeed..

"Schwab,Wilhelm K" <[hidden email]>
> Treating reals as complex (giving them a zero imaginary part) is a bad
> idea.   Reasons include:
>
> (1) need float and double for FFI
??

> (2) compatibility with other dialects

Squeak and Pharo already have some invompatabilities (e.g. not requiring #initialize after #new). I do agree that dialect compatibility is a good thing in general.

> (3) avoid wasting space to hold unneeded imaginary parts

No need for extra space.

Number>>real
  ^self

Number>>imaginary
  ^0

> Sig is correct to point out that sometimes one wants to do purely real
> arithmetic with the domains of various functions restricted as appropriate.
>  Complex numbers should be separate from reals.

I think that this might be approached differently.

Thought experiment.

I have a Smalltalk without negative numbers (How can you take something away from nothing? Screen pixels start at 0@0 I can't draw pixels off-screen! If I get "negative" pixels I have to check every pixel calculation to see if I am on screen or not.).

So now I make a package which supplies NegativeNumbers.

The argument is that this changes the behavior which people rely on (breaks existing code) and that nobody uses these imaginary negative things anyway.

Should one not allow this package?


Note that again, for consistency, I suggest that making Complex a package implies removing the current Complex implementation.  If a Complex package exists, I expect  (-1 sqrt) to give 1i.

My intent is for consistency.  Packages allow for completeness.  Can we both be happy?

$0.02,
-KenD

_______________________________________________
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

On Aug 14, 2009, at 10:38 AM, Ken.Dickey wrote:

> Squeak and Pharo already have some invompatabilities (e.g. not  
> requiring
> #initialize after #new).

I'm sort of a newbie, can you elaborate on not requiring #initialize  
after #new somewhat, or point me to where it is documented, I searched  
around a little bit, but quickly got lost.

Thanks!

DZ

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

A default implementation of new on the class sends initialize to the
instance by default.

All you need to do is implement the initialize method if you want to.

Cheers mike
On Friday, August 14, 2009, Daniel P Zepeda <[hidden email]> wrote:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project