From: Janos Blazi
Subject: Matrix type bis
Date: 
Message-ID: <bock-840sv4/INN-2.2.1/bunt@broadway.news.is-europe.net>
We saw that A LISP programmer would not want to "overload" the "+" operator
to make it work with matrices. But I think this kind of overloading does not
work well in C++ either, though it is possible.
Let us suppose we have declared a matrix class and we have only matrices in
Mat(n) for an arbitrary but fixed natural n and we want to overload "+" to
realize addition in the ring Mat(n). Then if we write A=B+C, with A,B,C
being elements of Mat(n), we come across a strange problem: While "+" is
computing the elements of the sum matrix it has to store these elements
*somewhere*. Now it is quite clear, where these matrix element should be
stored: they should be stores in A! but there is (as far as I know) no way
to communicate this information to the "+" operator. So it would most likely
allocate a temporary matrix tmp and store the computed matrix elements in
this temporary matrix. As there is no garbage collection, the elements of
the temporary matrix must be copied word for word into the result and this
is most definitely the last thing I want to do!
Of course I can circumvent this problem in several ways but then I will
loose the so called elegance of the object oriented paradigm. Probably I
would write a function that receives pointers to B, C *and A* but then I am
working in C.

I think the object oriented paradigm of C++ looks very elegant at first
sight but you have to pay the price for that in terms of performance.

Any comments? This is the best I can come up with. Obviously I cannot
compete with a psychopath as far as deep insights are concerned.

Janos Blazi

From: Jonathan Coupe
Subject: Re: Matrix type bis
Date: 
Message-ID: <843itu$flt$1@newsg4.svr.pol.co.uk>
Janos Blazi <······@netsurf.de> wrote in message
·······························@broadway.news.is-europe.net...
> .. if we write A=B+C, with A,B,C
> being elements of Mat(n), we come across a strange problem: While "+" is
> computing the elements of the sum matrix it has to store these elements
> *somewhere*. Now it is quite clear, where these matrix element should be
> stored: they should be stores in A! but there is (as far as I know) no way
> to communicate this information to the "+" operator. So it would most
likely
> allocate a temporary matrix tmp and store the computed matrix elements in
> this temporary matrix. As there is no garbage collection, the elements of
> the temporary matrix must be copied word for word into the result and this
> is most definitely the last thing I want to do!

There are at least two answers to this and related problems:

    (i) an enevelope idiom that uses smart pointers to reduce copying (See
Copilen's "Advanced C++")
    (ii) a smart compiler (eg KAI C++) that eliminates redundant temporay
variables during compilation.

Congratulations on having spotted the problem; a lot of C++ programmers
never do so.

Jonathan Coupe
From: Janos Blazi
Subject: Re: Matrix type bis
Date: 
Message-ID: <bernardino-8452ct/INN-2.2.1/bought@broadway.news.is-europe.net>
Thx. The book by Coplien is in our local library so I can take a look
tomorrow.
The second hint concerning smart compilers I did not understand, sorry.

It seems my original message has disappeared. How is this possible?

Janos Blazi

Jonathan Coupe <········@meanwhile.freeserve.co.uk> schrieb in im
Newsbeitrag: ············@newsg4.svr.pol.co.uk...
>
> Janos Blazi <······@netsurf.de> wrote in message
> ·······························@broadway.news.is-europe.net...
> > .. if we write A=B+C, with A,B,C
> > being elements of Mat(n), we come across a strange problem: While "+" is
> > computing the elements of the sum matrix it has to store these elements
> > *somewhere*. Now it is quite clear, where these matrix element should be
> > stored: they should be stores in A! but there is (as far as I know) no
way
> > to communicate this information to the "+" operator. So it would most
> likely
> > allocate a temporary matrix tmp and store the computed matrix elements
in
> > this temporary matrix. As there is no garbage collection, the elements
of
> > the temporary matrix must be copied word for word into the result and
this
> > is most definitely the last thing I want to do!
>
> There are at least two answers to this and related problems:
>
>     (i) an enevelope idiom that uses smart pointers to reduce copying (See
> Copilen's "Advanced C++")
>     (ii) a smart compiler (eg KAI C++) that eliminates redundant temporay
> variables during compilation.
>
> Congratulations on having spotted the problem; a lot of C++ programmers
> never do so.
>
> Jonathan Coupe
>
>
From: Jonathan Coupe
Subject: Re: Matrix type bis
Date: 
Message-ID: <8489bj$e8m$1@news8.svr.pol.co.uk>
o
Janos Blazi <······@netsurf.de> wrote in message
·······································@broadway.news.is-europe.net...

> The second hint concerning smart compilers I did not understand, sorry.

Look at Kuck associates website. It's easy to fin with +KAI +C++ on
altavista.

Jonathan
From: Marco Antoniotti
Subject: Re: Matrix type bis
Date: 
Message-ID: <lw4scvqynf.fsf@parades.rm.cnr.it>
"Jonathan Coupe" <········@meanwhile.freeserve.co.uk> writes:

> Janos Blazi <······@netsurf.de> wrote in message
> ·······························@broadway.news.is-europe.net...
> > .. if we write A=B+C, with A,B,C
> > being elements of Mat(n), we come across a strange problem: While "+" is
> > computing the elements of the sum matrix it has to store these elements
> > *somewhere*. Now it is quite clear, where these matrix element should be
> > stored: they should be stores in A! but there is (as far as I know) no way
> > to communicate this information to the "+" operator. So it would most
> likely
> > allocate a temporary matrix tmp and store the computed matrix elements in
> > this temporary matrix. As there is no garbage collection, the elements of
> > the temporary matrix must be copied word for word into the result and this
> > is most definitely the last thing I want to do!
> 
> There are at least two answers to this and related problems:
> 
>     (i) an enevelope idiom that uses smart pointers to reduce copying (See
> Copilen's "Advanced C++")
>     (ii) a smart compiler (eg KAI C++) that eliminates redundant temporay
> variables during compilation.
> 
> Congratulations on having spotted the problem; a lot of C++ programmers
> never do so.

An idiom you can use (even in C++!) is to have an optional "result"
parameter where to store the values

	(defun matrix:* (a b &optional (result (matrix:make-*-result a b)))
	    ;; store the intermediate results into RESULT
            ;; return RESULT
           )

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Tim Bradshaw
Subject: Re: Matrix type bis
Date: 
Message-ID: <ey3ogbd37qz.fsf@cley.com>
* Janos Blazi wrote:

> I think the object oriented paradigm of C++ looks very elegant at first
> sight but you have to pay the price for that in terms of performance.

I think you've found one of the great gaping holes in C++ and other
pointer/immediate languages like it.  One of the standard complaints
about Lisp-family languages is that primitive operations in the
language take non-constant time.  But in C++, *assignment must copy*,
which not only can take non-constant time, but in many cases has
unclear semantics *as well*!

--tim
From: Janos Blazi
Subject: Re: Matrix type bis
Date: 
Message-ID: <belgian-845pou/INN-2.2.1/bolshoi@broadway.news.is-europe.net>
I should not say that this is whole. We should not expect too much.

I think C has very clean concepts that perfectly reflect the so called
von-Neumann architecture. It follows that the inherent abstraction level of
C is very low. (And C is very fast if you can solve your problems in C.
Often it is very, very difficult.)

Now C++ raises the abstraction level. It is somewhere halfway between C and
LISP (or maybe it is nearer to C than to LISP). So it is faster than LISP,
does not offer the abstraction level LISP does and it is more abstract than
C and it is most definitely slower. I feel that C++ is a bit murky.

Python or PERL for example are a further step in the LISP direction.

And here is the other side of the story: However bad C++ may be, Visual C++
is a wonderful product and it is a pity that there is no Visual LISP.

Janos Blazi

Tim Bradshaw <···@cley.com> schrieb in im Newsbeitrag:
···············@cley.com...
> * Janos Blazi wrote:
>
> > I think the object oriented paradigm of C++ looks very elegant at first
> > sight but you have to pay the price for that in terms of performance.
>
> I think you've found one of the great gaping holes in C++ and other
> pointer/immediate languages like it.  One of the standard complaints
> about Lisp-family languages is that primitive operations in the
> language take non-constant time.  But in C++, *assignment must copy*,
> which not only can take non-constant time, but in many cases has
> unclear semantics *as well*!
>
> --tim
From: Chris Double
Subject: Re: Matrix type bis
Date: 
Message-ID: <wkd7rtia63.fsf@double.co.nz>
"Janos Blazi" <······@netsurf.de> writes:

> And here is the other side of the story: However bad C++ may be,
> Visual C++ is a wonderful product and it is a pity that there is no
> Visual LISP.

Have you used Allegro CL on Windows? That's pretty visual...

Chris.
From: Janos Blazi
Subject: Re: Matrix type bis
Date: 
Message-ID: <birgit-847cad/INN-2.2.1/brimful@broadway.news.is-europe.net>
I have not used Allegro Cl yet but I think they have some sort of trial
version that is free and I'll download it. But still: I think that Visual
C++ is an outstanding product.

J.B.


Chris Double <·····@double.co.nz> schrieb in im Newsbeitrag:
··············@double.co.nz...
> "Janos Blazi" <······@netsurf.de> writes:
>
> > And here is the other side of the story: However bad C++ may be,
> > Visual C++ is a wonderful product and it is a pity that there is no
> > Visual LISP.
>
> Have you used Allegro CL on Windows? That's pretty visual...
>
> Chris.
From: Chris Double
Subject: Re: Matrix type bis
Date: 
Message-ID: <wkn1qwtwa4.fsf@double.co.nz>
"Janos Blazi" <······@netsurf.de> writes:

> I have not used Allegro Cl yet but I think they have some sort of
> trial version that is free and I'll download it.

Yes they do have a trial version. It's about 20 MB or so. It's nice
though if you like the VB/Delphi application building style.

> But still: I think that Visual C++ is an outstanding product.

What about it do you think of as outstanding?

Chris.
From: Christopher R. Barry
Subject: Re: Matrix type bis
Date: 
Message-ID: <87d7rqlkl4.fsf@2xtreme.net>
Chris Double <·····@double.co.nz> writes:

> > But still: I think that Visual C++ is an outstanding product.
> 
> What about it do you think of as outstanding?

(Guess:) Probably "Intellisense" completion and all the little wizards that
code your application for you....

Christopher
(I've never used VC++, but I generally hear good things about it--not
from Lisp people though. :)
From: Marco Antoniotti
Subject: Re: Matrix type bis
Date: 
Message-ID: <lw1z7zqyj9.fsf@parades.rm.cnr.it>
······@2xtreme.net (Christopher R. Barry) writes:

> Chris Double <·····@double.co.nz> writes:
> 
> > > But still: I think that Visual C++ is an outstanding product.
> > 
> > What about it do you think of as outstanding?
> 
> (Guess:) Probably "Intellisense" completion and all the little wizards that
> code your application for you....
> 
> Christopher
> (I've never used VC++, but I generally hear good things about it--not
> from Lisp people though. :)

You cannot "install" the beast withouth IE! It simply does not
work. :)

Cheers


-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Raymond Wiker
Subject: Re: Matrix type bis
Date: 
Message-ID: <873dsfwbrm.fsf@foobar.orion.no>
"Janos Blazi" <······@netsurf.de> writes:

> I have not used Allegro Cl yet but I think they have some sort of trial
> version that is free and I'll download it. But still: I think that Visual
> C++ is an outstanding product.

        Only if you mean "outstandingly bad". Visual Studio is only
suited for individual, inexperienced programmers who want to write
trivial applications.

-- 
Raymond Wiker, Orion Systems AS
+47 370 61150