Jocoplien@cs.com wrote:
In a message dated 8/25/02 10:16:43, lourenci@lsi.usp.br writes:
<< As I told you, I would never derive a real class from a complex class. I would extend the real class to the complex class. >>
To me, this is somewhat ridiculous.
As far as I remembered I studied complex number at high school more than thirty years ago! In Self you can indicate the coordinates through analytic geometry or in complex form. So I cannot really model it without reviewing things.
At best, such an approach would be very unhermeneutic :-) It is not thinking even at an epistemelogical level, let alone a hermeneutic level. The semiotics at this level are like runes in most of the languages you have mentioned.
Highly probable! I hope Jecel can contribute or Constantinos to the discussion if it is possible from a prototype concerned with modeling real number to derive another prototype concerned with modeling complex number or if this reasoning is highly independent or if it is right to develop a real class from a complex class.
In the book I talked about before (by Lamport) I think his claim is to get beyond runes to the fundamental nub of things. I am skeptical of such approaches because they suggest that the problem is independent of the solution taken.
My approach is seamless in all levels. Each further level must devise the hermeneutic reasoning of the domain level. And I mean the hermeneutic reasoning is not really explicit in the world around us. Mandelbrot revealed this through his geometry. SEmiotics revealed the world is meaningful but only semiotics shows how to perceive this. Only recently postquantum physicists perceive the world as above all information. Peirce perceived this from 1838 when he was born until 1914!:-)
Well I will proceed my reading from James Noble et al's Design patterns as signs. Metaphor is rather the way children see the world until seven years old! Since Selfers see the world as it really is and are able to factor out true commonalities by analogy to build a more complex prototype
I think this sort of reasoning deserves especial attention too. I hope someone can respond to my naïve formulation. Is is possible to derive a complex object from a real object in Self or any other language? Apparently they cover complete different realities.
Both self and C++ introduce their own kinds of problems, and that means the problem is modeled differently for the respective solution technologies. Different languages, different semiotics, different models.
Here's some real code; let's get concrete, and then abstract (or, if you prefer, use the concrete as a means for exhibiting the abstract). This all comes down to code at some point, and arguments short of code run the risk of being circular and imprecise. Can you show me how you would extend the following (or any) Real class to be a Complex?
Then maybe we will have a baseline should Jecel choose to contribute a self example...
class Real { public: friend Real operator+(const Real &r1, const Real &r2) { register Real retval = r1; retval += r2; return retval; } friend Real operator-(const Real &r1, const Real &r2) ... friend Real operator*(const Real &r1, const Real &r2) ... .... Real &operator+=(const Real &r1) { rep += r1.rep; return *this; } Real &operator-=(const Real &r1) { rep -= r1.rep; return *this; } Real &opeartor+=(const Real &r1) ... .... Real(double r1): rep(r1) { } Real(const Real &r1): rep(r1.rep) { } Real operator=(const Real &r1) { rep = r1.rep; return *this; } ~Real() { } private: double rep; };
class Complex: public (?) Real { ??? };
Bye Albertina
On Sunday 25 August 2002 16:17, Albertina Lourenci wrote:
Jocoplien@cs.com wrote:
In a message dated 8/25/02 10:16:43, lourenci@lsi.usp.br writes:
<< As I told you, I would never derive a real class from a complex class. I would extend the real class to the complex class. >>
To me, this is somewhat ridiculous.
It is from a static type viewpoint. But Self hides concrete types (or implementation types or whatever you call them) and has no model for abstract types (or protocols, or interfaces....) though such a model can be added by the programmer very easily.
Both self and C++ introduce their own kinds of problems, and that means the problem is modeled differently for the respective solution technologies. Different languages, different semiotics, different models.
Exactly.
Here's some real code; let's get concrete, and then abstract (or, if you prefer, use the concrete as a means for exhibiting the abstract). This all comes down to code at some point, and arguments short of code run the risk of being circular and imprecise. Can you show me how you would extend the following (or any) Real class to be a Complex?
Then maybe we will have a baseline should Jecel choose to contribute a self example...
class Real { public: friend Real operator+(const Real &r1, const Real &r2) { register Real retval = r1; retval += r2; return retval; } friend Real operator-(const Real &r1, const Real &r2) ... friend Real operator*(const Real &r1, const Real &r2) ... .... Real &operator+=(const Real &r1) { rep += r1.rep; return *this; } Real &operator-=(const Real &r1) { rep -= r1.rep; return *this; } Real &opeartor+=(const Real &r1) ... .... Real(double r1): rep(r1) { } Real(const Real &r1): rep(r1.rep) { } Real operator=(const Real &r1) { rep = r1.rep; return *this; } ~Real() { } private: double rep; };
Here I'll simplify the notation for creating new global slots a bit to make the text less ugly (you would do this graphically in Self anyway):
"shared behavior for all real objects" traits real = ( | parent* = traits clonable. + arg = ( copy += arg ). - arg = ( copy -= arg ). * arg = ( copy *= arg ). += arg = ( rep: rep + arg rep ). -= arg = ( rep: rep - arg rep ). *= arg = ( rep: rep * arg rep ). = arg = ( rep = arg rep ). | )
"the prototypical real object" real = ( | parent* = traits real. rep <- 0.0 | )
I think this is very close in spirit to your C++ code.
class Complex: public (?) Real { ??? };
traits complex = ( | parent* = traits real. += arg = ( rep: rep + arg rep. imp: imp + arg imp ). "warning! this depends on imp: returning self!" -= arg = ( rep: rep - arg rep. imp: imp - arg imp ). *= arg = ( rep: (rep * arg rep) -(imp * arg imp). imp: (rep * arg imp) +(imp * arg rep) ). = arg = ( (rep = arg rep) && [imp = arg imp] ). | )
complex = ( | parent* = traits complex. rep <- 0.0. imp <- 0.0 | )
This is really, really ugly and a real implementation would have to fit into the Self double dispatching scheme for numbers. But it does work. Adding a "imp = 0.0" slot to traits real would make things work even better.
-- Jecel
self-interest@lists.selflanguage.org