[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help with [] for defined types

From: David Bateman
Subject: Re: Help with [] for defined types
Date: Thu, 8 Jul 2004 13:53:56 +0200
User-agent: Mutt/1.4.1i

According to Paul Kienzle <address@hidden> (on 07/08/04):
> This is a restatement of the type explosion problem.  I guess it will
> work out that the types which care about each other will either
> have each other as prereqs or be part of the same package.

Exactly, only the types that have explicitly defined concat functions,
between them or a widening function that allows a concat function to be 
found could be concatenated.

So, its up to the author of the user type to setup the correct concat
functions with the type promotion.

> Okay, so the idea is that if you are really concerned, then
> use explicit conversion.  E.g.,
>        [ mytype(data); data; data; mytypestuff ]
> I'm not sure this would work for something like complex, since
> 1+0i is real.  Maybe we need an explicit complex() constructor?

That would certainly work and reduce the performance hit. But the
above case is not really that bad, as there is only a single promotion.
The fact is the current code, has a similar drawback as it determines
the types as it walks the list. So it equally has to promotion the 
matrix in the middle of the concatenation. So in this sense the use
of a binary CATOP just makes this cost clearer.

For the complex case it might have been clearer to do something like

sz = size(data); sz(1) = 0; [complex(zeros(sz)); data; data; complexstuff]

but even empty matrices are mutated back to matrices... If the
dot-m file complex.m was rewritten as an oct-file it might be
possible to avoid the maybe_mutate call that gives the conversion
back to matrices, but in that case "complex(randn(10)) + 1" would
still be a matrix, so that is just moving the problem elsewhere.
Better, to just accept the performance hit.

> Okay.  Only other detail you might want to consider is
> an eventual implementation of types in m-files.  Is this
> going to be possible/convenient, and maybe compatible?

The problems of user types in m-files and the concatenation are
seperate. As the CATOP stuff is basically identical to the BINOP
stuff, if the user type in an m-file has access to the binary
operators like +, -, *, /, etc then there is no reason to not have
access to the concatenation stuff either.


David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

reply via email to

[Prev in Thread] Current Thread [Next in Thread]