I do agree on your gripe about the globality (in the first proposal of mine I mentioned that), but I don't grasp in fully the "separated world concept".  Could you elaborate?


Em 14/08/2009 21:42, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu:

I really do not like the flag idea, because it is global.  What if there are two phases to something, one that uses complex numbers, and one that does not?  Since the complex numbers are the far less likely be needed and much newer feature to Smalltalk, the separate world design will be the cleaner and better accepted option.

Bill

---

From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak@bol.com.br
Sent: Friday, August 14, 2009 7:16 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

That's why I suggest (once Complex be loaded) a flag something like Smalltalk complexResultsOn and its counterpart to turn off be used instead.


Em 14/08/2009 20:53, John McIntosh < johnmci@smalltalkconsulting.com > escreveu:

Yes but we usually don't do explicit casting Like 2 asFloat * 3.0
We could but where does the implicit type conversion lie?


On 8/14/09, Schwab,Wilhelm K wrote:
> John,
>
> If I may be so presumptuous, the answer is to have people use #asComplex
> when they want complex results. -2 sqrt throws an error; -2 asComplex sqrt
> gives the complex (imaginary) result. Then we break no old code, we offer
> useful new features with minimal effort required to invoke them.
>
> Bill
>
>
>
> -----Original Message-----
> From: pharo-project-bounces@lists.gforge.inria.fr
> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M
> McIntosh
> Sent: Friday, August 14, 2009 4:55 PM
> To: Pharo-project@lists.gforge.inria .fr
> Subject: Re: [Pharo-project] Complex number support discussion
>
>
> On 14-Aug-09, at 1:04 PM, Schwab,Wilhelm K wrote:
>
>> John,
>>
>> That is not far from the eveolving conscensous opinion - I think we
>> can indeed claim to have a collective desire to leave integers and
>> floats as they are. One concern I have about your suggestion is what
>> happens when the user loads the complex package? Does existing code
>> break? It would given Ken's proposal. There are alternatives, and
>> they are discussed in this fairly extensive thread.
>>
>> Besides, someone wanting complex numbers will look for and load a
>> package to support them, as long as it is good code. Complex is fine
>> as far as it goes; some FFI magic to benefit from GSL functionality
>> would be nice. We should also have an analog to FloatArray that has
>> complex entries; again, a wrapper onto GSL would be a nice addition.
>>
>> I have no power over Ken; he can build what he wants. I would like to
>> see his energy directed toward creating something we can all use. I
>> suggest a layered proposal on the wiki and up or down votes on what
>> becomes part of Pharo. If the vote(s) split, we have benevolent
>> dictators to sort it out.
>>
>> Bill
>
> Ah, yes well I think I lost the 0.2 = (1/2) argument, so anything goes.
>
> I think the choice is either numbers + complex work as expected, or you just
> offer number then offer to load the complex logic as soon as someone wants
> -2 sqrt.
>
> Obviously the problem here is that for a vast r ange of programmers if you
> offer up -2 sqrt by default and it does not throw an excepti on they will be
> confused. Some of them likely have NO idea what a complex number is.
>
> Random thoughts.
>
> No-doubt there are abuses of math to string where people assume you have an
> integer like thing versus a complex number string.
>
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
& gt; Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


--
===========================================================================
John M. McIntosh
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project