Complex Solutions

>From: "Schwab,Wilhelm K" <[hidden email]>
...
>I have not been over all of it, but I have found that Real>>arcCosH and
> #arcTanH can answer a Complex.  I would rather not have to say it, but I do
> not get the sense that you have taken our concerns seriously.  We want the
> errors from Float when the domains are violated.  A mere #asComplex can be
> dividing line that puts the programmer in conrol.

Thanks.  I had not caught these.

>On this next minor point I can be talked out of it, but I would much prefer
> #cosh etc. to #cosH; it's easier to type and matches all conventional
> notation that I have seen.

I am trying to follow camelCase as I understand it.  One rubric from user
interfaces is that things which are distinct should *look* distinct.  I
personally perfer cosH to cosh because I know it is not a typo. That I really
mean cosH not cos.  

Let me know the proper thing to do here.

>Number>>angle should probably be called #argument, though I would argue that
> it should not exist as it is another example of implicit (however benign)
> coercion to complex numbers.

I am trying to follow conventions here for other languages which support
Complex data types [primarily Common Lisp and, Scheme].  An angle in radians
is what is returned.  Wny not call the function returning an angle to be
#angle ?

Again, let me know the proper thing to do in Smalltalk.

>Complex>>angle looks like it will answer zero for a value of zero??  AFAIK,
> there should be no direction for a zero vector.  In a way, it is splitting
> hairs because exact comparisons of floats are dubious, but it probably
> should raise an error for zero.

I am following ANSI X3J13 (they had a formal vote which declared the angle of
zero to be zero).  Let me know of a better refrerence.  [The problem with
standards is that there are so many to chose from ;^].

>Object Arts has long looked down on #as* and #is* methods.  With my bias
> toward their views confessed, #isComplex and #isNumberOrComplex realy
> should not exist, and even if they do, what are they doing in Object?
> #isNumberOrComplex raises concerns that there is too much blending of
> Complex into floats.

According to my recollection of _Squeak by Example_, #isFoo is a standard
ideom for a class #Foo.

#isNumberOrComplex is used to make double dispatch work in #=, now that
Complex instances answer false to isNumber.  

Do you have a better solution here?

#isNumberOrComplex was added to Object to make the test relatively cheap (#=
is used a lot, yes?).

If Complex does not interoperate, at least to some extent, with Floats how
would it be useful for anything?  Smalltalk without polymorphism ???

Better solutions?

>There are various uses of Taylor series corrections and some things that are
> computed directly in terms of exponentials.  My hunch is that robust
> scientific libraries will (hopefully) do these things well, and most of the
> transcendental functions, especially over complex numbers, should come from
> them when possible and reasonable.  The results will likely be faster and
> probably more accurate than what we can do in Smalltalk.

I agree that a better global solution for numbers is desired.  This is an
attempt for a small tweak to simply fix the problems I outlined.  These
problems exist in the current code base.

Thank you again for taking the time to look at this,
-KenD


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

Ken,

On #cosH vs. #cosh, etc.,I do not like what you have done, but it's hardly cause to start a war.  I would be more inclined to agree with your no-typo argument if you spelled out hyperbolic.  We write cos and cosh; I see no advantage to typing cosH, which could just as easily be errant as cosh.

#angle vs. #argument.  The terminology of modulus and argument is heavily drilled into engineers and physisists, so I would go with that inertia vs. anything from Scheme or Lisp.


=============
"If Complex does not interoperate, at least to some extent, with Floats how would it be useful for anything?  Smalltalk without polymorphism ???"

That's not it at all.  Sig and I hav been very clear on using polymorphism to get he expected behavior in each world, and how it can extend to (for example) exponentials of matrices.  I don't know how to make it more clear that we have done.  We object to implicit coercion which works against anyone interested only in real results.
=============



===============
>Complex>>angle looks like it will answer zero for a value of zero??  
>Complex>>AFAIK,
> there should be no direction for a zero vector.  In a way, it is
> splitting hairs because exact comparisons of floats are dubious, but
> it probably should raise an error for zero.

I am following ANSI X3J13 (they had a formal vote which declared the angle of zero to be zero).  Let me know of a better refrerence.  [The problem with standards is that there are so many to chose from ;^].
===============

ANSI is the same group that put an end to time as we know it in 2037 (maybe 2038); if you thought y2k was a mess, just wait until time_t wraps.  Zero vectors (and complex numbers act as vectors in this case) have no direction, and ANSI's vote does not change that.  Many times you have shown a desire to make things more mathematically correct; ANSI is just plain wrong here.  The only argument in their favor is that the distinction might be slightly vacant because computing a truly zero result is very unlikely in a floating point world.

Bill




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken Dickey
Sent: Saturday, August 29, 2009 3:43 PM
To: [hidden email]
Subject: [Pharo-project] Complex Solutions

>From: "Schwab,Wilhelm K" <[hidden email]>
...
>I have not been over all of it, but I have found that Real>>arcCosH and  
>#arcTanH can answer a Complex.  I would rather not have to say it, but
>I do  not get the sense that you have taken our concerns seriously.  We
>want the  errors from Float when the domains are violated.  A mere
>#asComplex can be  dividing line that puts the programmer in conrol.

Thanks.  I had not caught these.

>On this next minor point I can be talked out of it, but I would much
>prefer  #cosh etc. to #cosH; it's easier to type and matches all
>conventional  notation that I have seen.

I am trying to follow camelCase as I understand it.  One rubric from user interfaces is that things which are distinct should *look* distinct.  I personally perfer cosH to cosh because I know it is not a typo. That I really mean cosH not cos.  

Let me know the proper thing to do here.

>Number>>angle should probably be called #argument, though I would argue
>Number>>that
> it should not exist as it is another example of implicit (however
> benign) coercion to complex numbers.

I am trying to follow conventions here for other languages which support Complex data types [primarily Common Lisp and, Scheme].  An angle in radians is what is returned.  Wny not call the function returning an angle to be #angle ?

Again, let me know the proper thing to do in Smalltalk.

>Complex>>angle looks like it will answer zero for a value of zero??  
>Complex>>AFAIK,
> there should be no direction for a zero vector.  In a way, it is
> splitting hairs because exact comparisons of floats are dubious, but
> it probably should raise an error for zero.

I am following ANSI X3J13 (they had a formal vote which declared the angle of zero to be zero).  Let me know of a better refrerence.  [The problem with standards is that there are so many to chose from ;^].

>Object Arts has long looked down on #as* and #is* methods.  With my
>bias  toward their views confessed, #isComplex and #isNumberOrComplex
>realy  should not exist, and even if they do, what are they doing in Object?
> #isNumberOrComplex raises concerns that there is too much blending of  
>Complex into floats.

According to my recollection of _Squeak by Example_, #isFoo is a standard ideom for a class #Foo.

#isNumberOrComplex is used to make double dispatch work in #=, now that Complex instances answer false to isNumber.  

Do you have a better solution here?

#isNumberOrComplex was added to Object to make the test relatively cheap (#= is used a lot, yes?).

If Complex does not interoperate, at least to some extent, with Floats how would it be useful for anything?  Smalltalk without polymorphism ???

Better solutions?

>There are various uses of Taylor series corrections and some things
>that are  computed directly in terms of exponentials.  My hunch is that
>robust  scientific libraries will (hopefully) do these things well, and
>most of the  transcendental functions, especially over complex numbers,
>should come from  them when possible and reasonable.  The results will
>likely be faster and  probably more accurate than what we can do in Smalltalk.

I agree that a better global solution for numbers is desired.  This is an attempt for a small tweak to simply fix the problems I outlined.  These problems exist in the current code base.

Thank you again for taking the time to look at this, -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

Em  30/08/2009  13:36, Schwab,Wilhelm  K  < [hidden email]  >
escreveu: Let me see if I understand your point then: it is OK in your view that
we can do:

1i squared. retuning "-1 + 0i" so a Complex, but

(1i squared) sqrt. raises an error?

Or should we follow your logic and even when the imaginary part of a
Complex is zero it should not be automatically converted in a real
number?

Please not that once the programmer wrote:

1i whatever he already made her/his choice to use Complex numbers, right?

Oh well, interesting way of looking at things: a non sequitur comment
on size of time_t and a dismissal of an agreed upon Standard.  You'll
have a lot of problem using complex  numbers as you want if you don't
follow IEEE  and ANSI stipulations on the angle of certain operations
when voltage is squared to calculate power or the angle of it (which
follows the angle of the load) as there is more than a single
mathematical correct answer.

Back to mathematical purity, then we have a conundrum: as Ken wrote
several times Complex is considered a superset of Real numbers in
mathematics is Smalltalk class hierarchy that "decided" to consider
Number as a subclass of Magnitude that has to respond to #<, but this
is not necessary in mathematics in general, no reference about number
theory you find such necessary condition.


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

 
====================
Let me see if I understand your point then: it is OK in your view that we can do:

1i squared. retuning "-1 + 0i" so a Complex, but

(1i squared) sqrt. raises an error?
====================

You apparently do NOT understand.  1i squared would answer a Complex, so it would respond favorably to #sqrt.


==================
Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number?
==================

Yes.  It's not "even when" - just don't do conversions when (you think) floating points numbers match.


============
1i whatever he already made her/his choice to use Complex numbers, right?
============

Right.  So don't try to turn it back into a Float and all will be well.




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Sunday, August 30, 2009 4:27 PM
To: [hidden email]
Subject: Re: [Pharo-project] Complex Solutions

Em  30/08/2009  13:36, Schwab,Wilhelm  K  < [hidden email]  >
escreveu: Let me see if I understand your point then: it is OK in your view that we can do:

1i squared. retuning "-1 + 0i" so a Complex, but

(1i squared) sqrt. raises an error?

Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number?

Please not that once the programmer wrote:

1i whatever he already made her/his choice to use Complex numbers, right?

Oh well, interesting way of looking at things: a non sequitur comment on size of time_t and a dismissal of an agreed upon Standard.  You'll have a lot of problem using complex  numbers as you want if you don't follow IEEE  and ANSI stipulations on the angle of certain operations when voltage is squared to calculate power or the angle of it (which follows the angle of the load) as there is more than a single mathematical correct answer.

Back to mathematical purity, then we have a conundrum: as Ken wrote several times Complex is considered a superset of Real numbers in mathematics is Smalltalk class hierarchy that "decided" to consider Number as a subclass of Magnitude that has to respond to #<, but this is not necessary in mathematics in general, no reference about number theory you find such necessary condition.


_______________________________________________
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

>From: "Schwab,Wilhelm K" <[hidden email]>
...
>On #cosH vs. #cosh, etc.,I do not like what you have done, but it's hardly
> cause to start a war.  I would be more inclined to agree with your no-typo
> argument if you spelled out hyperbolic.  We write cos and cosh; I see no
> advantage to typing cosH, which could just as easily be errant as cosh.

I don't understand your comment.  

"cos" and "cosh" differ in a single, lower case character.  In a line of code
where I expect to see "cos" but the text is actually "cosh" I would be more
likely to misread the text as "cos" than if the text is "cosH".  In this case
the capital is distinctive.  It clues the reader to the difference.

[I once had a bug in a Fortran program where 1 was substituted for l (ell) but
in the punch card font, it was very difficult to distinguish this].


>#angle vs. #argument.  The terminology of modulus and argument is heavily
> drilled into engineers and physisists, so I would go with that inertia vs.
> anything from Scheme or Lisp.

Thanks.  I'll make the change.


>>Complex>>angle looks like it will answer zero for a value of zero??
>>Complex>>AFAIK,
>> there should be no direction for a zero vector.  In a way, it is
>> splitting hairs because exact comparisons of floats are dubious, but
>> it probably should raise an error for zero.

I'll raise an error.  Zero divide?


One again, thanks.
-KenD

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

Ken,

Understood about punch cards, and in fact I have some loose methods in String to avoid such hassles with hard to spot spellings.  That said, I simply disagree with you on #cosh vs. #cosH.  As I said, I'm not particularly invested in the outcome; I just find it cumbersome to type and to read, and despite that, would not conclude that cosH is not a typo - it would depend on the circumstances.  As I said, I'm not planning any major troop movements over this one.

As for the zero vector, it is hard to say.  Note that a nearly zero vector is going to have a very poorly defined direction in that the result will likely be dominated by roundoff error.  Often there is a better way to compute such things; a rearrangment of governing equations can make a world of difference - that's not something you can fix, it will be problem-specific how one would avoid computing the argument in tricky situations.  One possible approach is to simply compute the angle the same way for all values and let under/over flow errors take care of the garbage.  Another would be to raise an error.  Finally, you might define #argument, #argumentIfSmall: (takes a block for the troublesome case) and #argumentIEEE to use their convetion.

Something that deserves a careful look is the test for floats being close to each other.  I have been supicious about that for a while, and on first glance, Dolphin seems to handle it very differently from the way Squeak does.  IMHO, being different from Dolphin is cause for a good think.  We shouls also see how VW handles it.

Just looking at #closeTo:, it appears to "think" that 10^-4 is a good threshold, and that is questionable depending on the scales involved, and is far from the smallest float that can be reasonable represented.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken Dickey
Sent: Sunday, August 30, 2009 6:10 PM
To: [hidden email]
Subject: Re: [Pharo-project] Complex Solutions

>From: "Schwab,Wilhelm K" <[hidden email]>
...
>On #cosH vs. #cosh, etc.,I do not like what you have done, but it's
>hardly  cause to start a war.  I would be more inclined to agree with
>your no-typo  argument if you spelled out hyperbolic.  We write cos and
>cosh; I see no  advantage to typing cosH, which could just as easily be errant as cosh.

I don't understand your comment.  

"cos" and "cosh" differ in a single, lower case character.  In a line of code where I expect to see "cos" but the text is actually "cosh" I would be more likely to misread the text as "cos" than if the text is "cosH".  In this case the capital is distinctive.  It clues the reader to the difference.

[I once had a bug in a Fortran program where 1 was substituted for l (ell) but in the punch card font, it was very difficult to distinguish this].


>#angle vs. #argument.  The terminology of modulus and argument is heavily
> drilled into engineers and physisists, so I would go with that inertia vs.
> anything from Scheme or Lisp.

Thanks.  I'll make the change.


>>Complex>>angle looks like it will answer zero for a value of zero??
>>Complex>>AFAIK,
>> there should be no direction for a zero vector.  In a way, it is
>> splitting hairs because exact comparisons of floats are dubious, but
>> it probably should raise an error for zero.

I'll raise an error.  Zero divide?


One again, thanks.
-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

I have updated PharoInbox with a newer slice:
    SLICE-basic-Complex-KenDickey.3

Float hyperbolic trig methods no longer return Complex answers.
Renamed: #angle -> #argument, #magnitude -># modulus.
Added more unit tests.

Thanks again for suggestions,
-KenD


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

Bill,

I have already said that I think IEEE floats tend to give the wrong answer
fast.  Better solutions are hard to come by, however, as they definately depend
on the problem domain.

E.g. Apple's old plot program used interval arithmetic and did a great job
with functions like x * sin(1/x) near zero.  You could zoom in time after time
and still get an accurate plot -- where IEEE floats are useless. Interval math
is also great when you have measurement error and you can't fool yourself
about error analysis. It is sure helpful to know the difference between
3.023+/-0.001 and 3.023+/-2e56 .    Interval math does have splits and it is
sometimes useful to calculate the probability distribution of the value in the
interval.  No perfect world, sigh.

If you are using ideal mathematics, on the other hand, there are exact real
representations which can be used, but these are pretty heavy weight for day
to day computing.

Another day; a little better approximation,
-KenD

>From: "Schwab,Wilhelm K" <[hidden email]>
...

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

While updating software, I experienced a disconect in  my DSL, then a
exception raised (please read on) and as you may sse in the attached
screenshot, the text pane where the method source code is shown, got crossed
with a red background. I saw this effect happening but have not recorded the
scenario. What is the code behind that makes the pane to get "crossed", what
are the circumstances ?

Regards, Carlos

-----Mensaje original-----
De: [hidden email]
[mailto:[hidden email]]En nombre de Ken
Dickey
Enviado el: Lunes, 31 de Agosto de 2009 01:25 a.m.
Para: [hidden email]
Asunto: Re: [Pharo-project] Complex Solutions


I have updated PharoInbox with a newer slice:
    SLICE-basic-Complex-KenDickey.3

Float hyperbolic trig methods no longer return Complex answers.
Renamed: #angle -> #argument, #magnitude -># modulus.
Added more unit tests.

Thanks again for suggestions,
-KenD


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



--
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: 10/03/2008
11:07 a.m.


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

Em  30/08/2009  18:37, Schwab,Wilhelm  K  < [hidden email]  escreveu:
>
>
>  ==================== Let me see if I understand your point then: it
> is OK in your view that we can do:
>  1i squared. retuning "-1 + 0i" so a Complex, but
>  (1i squared) sqrt. raises an error?  ====================
>  You  apparently  do  NOT  understand.  1i squared  would  answer  a
> Complex, so it would respond favorably to #sqrt.

Bill on the *present* state of affairs, Ken's description of the problem stands as *I* wrote, not as your analysis. Please observe carefully that once 1i is squared it "becomes back" a non complex number '-1'. THIS is the asymmetry I'm writing about.

>
>  ================== Or should we follow your logic and even when the
> imaginary part of  a Complex is zero it  should not be automatically
> converted in a real number?  ==================
>  Yes. It's  not "even  when" - just  don't do conversions  when (you
> think) floating points numbers match.

OK, then we agree that any operation on a Complex should not coalesce it to non complex anymore.
 
>
>  ============  1i whatever  he already  made her/his  choice  to use
> Complex numbers, right?  ============
>  Right. So don't  try to turn it  back into a Float and  all will be
> well.
>

Yes. I see consistency with, although I still think the other way is better :-)


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

On Aug 31, 2009, at 6:20 44PM, Carlos Crosetti wrote:

The red crossing happens when an error occurs in the morph rendering  
code, usually instead of frying your image.
When the error occured in the method pane, I'd say it's usually a good  
idea to just ditch the image anyways though, because if the model it  
relies on to properly draw the method is corrupted, there's probably  
more lurking in the shadows.

Needless to say,  error-recovery code of Monticello when a network  
disappears during an update probably could use some work :)
Or look into atomic loading, alternatively wait for MC2 to someday be  
usable and hope it fixes things.

Cheers,
Henry


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

Thanks for the propmt reply-
To workaround on a broken download, i think is easy and of very low
priority.

The morph rendering is something i also got when trying some UITheme
samples....

-----Mensaje original-----
De: [hidden email]
[mailto:[hidden email]]En nombre de Henrik
Johansen
Enviado el: Lunes, 31 de Agosto de 2009 05:17 p.m.
Para: [hidden email]
Asunto: Re: [Pharo-project] method pane got crossed



On Aug 31, 2009, at 6:20 44PM, Carlos Crosetti wrote:

The red crossing happens when an error occurs in the morph rendering
code, usually instead of frying your image.
When the error occured in the method pane, I'd say it's usually a good
idea to just ditch the image anyways though, because if the model it
relies on to properly draw the method is corrupted, there's probably
more lurking in the shadows.

Needless to say,  error-recovery code of Monticello when a network
disappears during an update probably could use some work :)
Or look into atomic loading, alternatively wait for MC2 to someday be
usable and hope it fixes things.

Cheers,
Henry


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



--
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: 10/03/2008
11:07 a.m.



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

On Aug 31, 2009, at 11:47 44PM, Carlos Crosetti wrote:

> Thanks for the propmt reply-
> To workaround on a broken download, i think is easy and of very low
> priority.
>
> The morph rendering is something i also got when trying some UITheme
> samples....
Please give step on how to reproduce in a bugtracker issue.

Cheers,
Henry

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