#< if at first you dont succeed..

A newbie - welcome!  We're always happy to spread the addiction.  To find out for yourself, do this:

  1) open a workspace, type Object new.
  2) select the new text, right click and choose debug-it
  3) step into #new, and note that it take you to
        ^self basicNew initialize

At the risk of oversimplifying, that creates a no-frills instance and then invokes #initialize.  Not all Smalltalks do this; it is either a bug or a feature depending on one's perspective, though I confess I have bigger things to worry about at present.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel P Zepeda
Sent: Friday, August 14, 2009 11:52 AM
To: [hidden email]
Subject: [Pharo-project] Incompatibilities was: #< if at first you dont succeed..


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

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

and besides, one could always redefine #new in subclasses to avoid
calling #initialize

2009/8/14 Schwab,Wilhelm K <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.

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

Ken,

I think I can see your point, but I propose you a practical experiment. In your Pharo image on the Workspace do it:

-1 inspect

You should get a SmallInteger.  Now SmallInteger behaviour is flag as error when you attempt sqrt on it.  Complex introduction on the image should not silently change this behaviour.

Every Smalltalk implementation I'm aware of, and IIRC ANSI compliant included, do that way, so in the context of Smalltalk it's unexpected these results start to come as Complex.

 

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

"Schwab,Wilhelm K"
> 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

Schwab,Wilhelm K
> 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.

My interpretation of the responses I have received is "Change breaks History,
we have a strong history" not "these suggestions are worse approximations to
mathematics".

I accept the first reasoning for Squeak.  Squeak supports history (backward
compatible) at the expense of, e.g., ANSI Smalltalk closures.

Pharo has a slightly different goal set and speaks of "reinventing Smalltalk".

I believe the changes I suggested better approximate mathematics and logic.

I would prefer to see arguments that I am doing bad math, not that "doing
better math is a change that we don't want".

Once again, the discussion here implies that the Complex class should be
removed from Pharo-Core into its own Package.

======
BTW, I fail too see the logic that (-4 sqrt) raises an exception but that (-3
ln) answers a NaN.  I would expect both cases to raise exceptions.  Any hints
on why this is the case?  Perhaps both cases should raise and exception with
the option to load a/the Complex package?
======

Thanks again for your thoughtful consideration and input,
-KenD

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

On Aug 14, 2009, at 5:38 PM, Ken.Dickey wrote:

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


no this is the same in squeak and pharo since 3.7

Stef

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

2009/8/15 kend <[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.
This is strictly mathematical behavior, same as division does not
defines a value for zero.

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.

> I would prefer to see arguments that I am doing bad math, not that "doing
> better math is a change that we don't want".
>
You not doing bad math or better math, you doing _different_ math.
Both could live in parallel, but you proposing to scratch one in favor of other.
Good that you noticed such inconsistency. I agree that in both cases
these functions should behave similar as well as any
other functions which argument(s) lying out of the range(s) defined for them.
But again, the behavior of such functions should not change in the
presence/absence of Complex numbers.

> Thanks again for your thoughtful consideration and input,
> -KenD
>
> _______________________________________________
> 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

Taking a hint from the comments (yes, I do listen), here is a "less
complex" :) solution:

Complex>>
< aNumber
        "Not defined on Complex numbers"

        ^self asReal < aNumber asReal

Complex>>
asReal
        "Answer real-part of self if imaginary is zero else, error"
        (imaginary = 0)
        ifTrue: [^real]
        ifFalse: [self error: 'Can''t convert to real']

Better?

-KenD

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

2009/8/15 Ken.Dickey <[hidden email]>:
By reading a comment:  "Not defined on Complex numbers"
i wonder why implementation is different than following:


Complex>>
 < aNumber
        "Not defined on Complex numbers"

        self shouldNotImplement

;)

But yes, given the fact that Complex numbers could be used by someone
in code as real numbers, and therefore expecting #< to work, an
implementation proposed by you is plausible.

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

Ken,

As a frequent user of complex numbers, I go from real to complex and back and very deliberately.  In the most common scenarios, the end game involves complex numbers that should be real (imaginary parts being only roundoff error).  I (cautiously) ignore the roundoff, compare the real parts and sometimes the modului of compex numbers.  Your proposed implementation is ok, but I have a hard time seeing it being useful.

Bill



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Saturday, August 15, 2009 5:04 AM
To: [hidden email]
Subject: Re: [Pharo-project] #< if at first you dont succeed..

2009/8/15 Ken.Dickey <[hidden email]>:
By reading a comment:  "Not defined on Complex numbers"
i wonder why implementation is different than following:


Complex>>
 < aNumber
        "Not defined on Complex numbers"

        self shouldNotImplement

;)

But yes, given the fact that Complex numbers could be used by someone in code as real numbers, and therefore expecting #< to work, an implementation proposed by you is plausible.

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

Pending your solution be accepted for the Complex implementation, I suggest the following changes in your code:

Complex>>asReal
"Answer real-part of self if imaginary is zero else, error"
imaginary isZero
ifTrue: [^real].
self error: 'Can''t convert to real'

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

Taking a hint from the comments (yes, I do listen), here is a "less
complex" :) solution:

Complex>>
< aNumber
"Not defined on Complex numbers"

^self asReal < aNumber asReal

Complex>>
asReal
"Answer real-part of self if imaginary is zero else, error"
(imaginary = 0)
ifTrue: [^real]
ifFalse: [self error: 'Can''t convert to real']

Better?

-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