Posted by
Igor Stasenko on
Aug 15, 2009; 5:12pm
URL: https://forum.world.st/if-at-first-you-dont-succeed-tp1303541p1303543.html
2009/8/15 Ken.Dickey <
[hidden email]>:
>> i disagree.
>> As i said earlier, a square root function result is not defined for
>> arguments less than zero in real (R) set.
>
> Right, only for complex (C). R < C [C contains R].
>
>> This is strictly mathematical behavior, same as division does not
>> defines a value for zero.
>
> My _Elementary Functions_ book has a nice section which defines the square
> root of -1 to be 1i.
>
Is it hard to understand that we are talking about completely
different functions?
Both are square root, but one is operator R -> R, while another is
operator C -> C (assuming that R is a subset of C).
For instance , a matrix algebra also defines a matrix multiplication
operator (*),
but it behaves completely different from scalar multiplication operator (*),
its not symmetic , and there is no reverse operation (division - only
partial, for matrices which can be reversed).
So, what will happen, if you try to 'unify' both operators to be
matrix multiplication?
Do you ready to sacrifice the symmetry of scalar multiplication,
because matrix multiplication is more generic?
> I pick up _Handbook of Physical Calculations_ and find an entire section on
> the mathematics of alternating current which uses complex math exclusively.
>
> I see why, given Smalltalk's history, one does not wish to change the way
> things are done. This is a bit different from implying complex mathematics
> is not mathematics.
>
I don't see how it can be related to Smalltalk history. I learnt math
more than a 15 years ago, including complex numbers
and i remember the distinction between functions which operating
strictly in real set, and ones which operating over complex plane,
and difference between them. They are not same!
>> Just think about, how many code i could break, if i return an Infinity
>> (or something like this) as a result of division by zero instead
>> of signaling error.
>
> My recollection (again, not to be trusted) is that Java returns an IEEE
> infinity rather than throwing an exception. I do not recommend this either,
> which is why I am puzzled by #ln returning a NaN.
>
> Again, my recommendation is that the current Complex implementation be removed
> from Pharo-Core.
>
> Reluctant as I am to suggest it, an allowComplexResults global preference
> could be used, with the usual "Here Be Dragons" warnings. Such a preference
> would clearly state that it is to allow functions like #ln and #sqrt to
> return complex results and would only be settable if a Complex number package
> was loaded.
>
> Cheers,
> -KenD
>
> PS: My apologies, but my laptop died and I am borrowing time on someone
> else's computer. I intent to browse "sqrt senders" when I get another
> machine to see what code is breaking.
>
> _______________________________________________
> Pharo-project mailing list
>
[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