#< if at first you dont succeed..

> i disagree.
> As i said earlier, a square root function result is not defined for
> arguments less than zero in real (R) set.

Right, only for complex (C).  R < C   [C contains R].

> This is strictly mathematical behavior, same as division does not
> defines a value for zero.

My _Elementary Functions_ book has a nice section which defines the square
root of -1 to be 1i.

I pick up _Handbook of Physical Calculations_ and find an entire section on
the mathematics of alternating current which uses complex math exclusively.

I see why, given Smalltalk's history, one does not wish to change the way
things are done.  This is a bit different from implying complex mathematics
is not mathematics.

> Just think about, how many code i could break, if i return an Infinity
> (or something like this) as a result of division by zero instead
> of signaling error.

My recollection (again, not to be trusted) is that Java returns an IEEE
infinity rather than throwing an exception.  I do not recommend this either,
which is why I am puzzled by #ln returning a NaN.

Again, my recommendation is that the current Complex implementation be removed
from Pharo-Core.

Reluctant as I am to suggest it, an allowComplexResults global preference
could be used, with the usual "Here Be Dragons" warnings.  Such a preference
would clearly state that it is to allow functions like #ln and #sqrt to
return complex results and would only be settable if a Complex number package
was loaded.

Cheers,
-KenD

PS:  My apologies, but my laptop died and I am borrowing time on someone
else's computer.  I intent to browse "sqrt senders" when I get another
machine to see what code is breaking.

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

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

> My _Elementary Functions_ book has a nice section which defines the square
> root of -1 to be 1i.

Yes but pay attention to the name Elementary Functions. The root of an equation x² = -1 is 1i. There is no definition of square roots of Real numbers.  That's why our ancestors used to call them "impossible roots" and afterwards "imaginary".  The consquence your reasoning would be to say that the square root of positive number has to return a tuple #(sqrt -sqrt), which is not right because the later is the result of an equation not a square root...

> I pick up _Handbook of Physical Calculations_ and find an entire section on
> the mathematics of alternating current which uses complex math exclusively.

Again: complex math is used for domain specific realm, and if you look carefully even there you'll see the need to "specialize" complex math as for working with electrical engineering we standards taking care of the ambiguities that arise from the results coming from "pure" complex arithmetics.

 

> i disagree.
> As i said earlier, a square root function result is not defined for
> arguments less than zero in real (R) set.

Right, only for complex (C). R < C [C contains R].

> This is strictly mathematical behavior, same as division does not
> defines a value for zero.

My _Elementary Functions_ book has a nice section which defines the square
root of -1 to be 1i.

I pick up _Handbook of Physical Calculations_ and find an entire section on
the mathematics of alternating current which uses complex math exclusively.

I see why, given Smalltalk's history, one does not wish to change the way
things are done. This is a bit different from implying complex mathematics
is not mathematics.

> Just think about, how many code i could break, if i return an Infinity
> (or something like this) as a result of division by zero instead
> of signaling error.

My recollection (again, not to be trusted) is that Java returns an IEEE
infinity rather than throwing an exception. I do not recommend this either,
which is why I am puzzled by #ln returning a NaN.

Again, my recommendation is that the current Complex implementation be removed
from Pharo-Core.

Reluctant as I am to suggest it, an allowComplexResults global preference
could be used, with the usual "Here Be Dragons" warnings. Such a preference
would clearly state that it is to allow functions like #ln and #sqrt to
return complex results and would only be settable if a Complex number package
was loaded.

Cheers,
-KenD

PS: My apologies, but my laptop died and I am borrowing time on someone
else's computer. I intent to browse "sqrt senders" when I get another < br />machine to see what code is breaking.

_______________________________________________
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/15 Ken.Dickey <[hidden email]>: Is it hard to understand that we are talking about completely
different functions?
Both are square root, but one is operator R -> R, while another is
operator C -> C (assuming that R is a subset of C).

For instance , a matrix algebra also defines a matrix multiplication
operator (*),
but it behaves completely different from scalar multiplication operator (*),
its not symmetic , and there is no reverse operation (division - only
partial, for matrices which can be reversed).
So, what will happen, if you try to 'unify' both operators to be
matrix multiplication?
Do you ready to sacrifice the symmetry of scalar multiplication,
because matrix multiplication is more generic?

> I pick up _Handbook of Physical Calculations_ and find an entire section on
> the mathematics of alternating current which uses complex math exclusively.
>
> I see why, given Smalltalk's history, one does not wish to change the way
> things are done.  This is a bit different from implying complex mathematics
> is not mathematics.
>
I don't see how it can be related to Smalltalk history. I learnt math
more than a 15 years ago, including complex numbers
and i remember the distinction between functions which operating
strictly in real set, and ones which operating over complex plane,
and difference between them. They are not same!



--
Best regards,
Igor Stasenko AKA sig.

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

Ken,

Agreed on Nan; I doubt there will be any resistance to making ln signal an error with non-positive arguments.  You are taking a bit of a leap to say that any of us have suggested that complex variable theory is not mathematics.  A few of have said that restrictions to the reals of various functions are valid and useful.  We have already described how to respect that and provide complex numbers at the same time.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey
Sent: Saturday, August 15, 2009 11:45 AM
To: [hidden email]
Subject: [Pharo-project] #< if at first you dont succeed..

> i disagree.
> As i said earlier, a square root function result is not defined for
> arguments less than zero in real (R) set.

Right, only for complex (C).  R < C   [C contains R].

> This is strictly mathematical behavior, same as division does not
> defines a value for zero.

My _Elementary Functions_ book has a nice section which defines the square root of -1 to be 1i.

I pick up _Handbook of Physical Calculations_ and find an entire section on the mathematics of alternating current which uses complex math exclusively.

I see why, given Smalltalk's history, one does not wish to change the way things are done.  This is a bit different from implying complex mathematics is not mathematics.

> Just think about, how many code i could break, if i return an Infinity
> (or something like this) as a result of division by zero instead of
> signaling error.

My recollection (again, not to be trusted) is that Java returns an IEEE infinity rather than throwing an exception.  I do not recommend this either, which is why I am puzzled by #ln returning a NaN.

Again, my recommendation is that the current Complex implementation be removed from Pharo-Core.

Reluctant as I am to suggest it, an allowComplexResults global preference could be used, with the usual "Here Be Dragons" warnings.  Such a preference would clearly state that it is to allow functions like #ln and #sqrt to return complex results and would only be settable if a Complex number package was loaded.

Cheers,
-KenD

PS:  My apologies, but my laptop died and I am borrowing time on someone else's computer.  I intent to browse "sqrt senders" when I get another machine to see what code is breaking.

_______________________________________________
Pharo-project mailing list
[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