[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Class of User Types [Was: Moving code from octave-forge to octave [W
From: |
David Bateman |
Subject: |
Re: Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]] |
Date: |
Fri, 25 Feb 2005 14:24:54 +0100 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20040923) |
Paul Kienzle wrote:
On Feb 25, 2005, at 4:20 AM, David Bateman wrote:
How do you save and load such beasts from files?
Does typeinfo give more complete information?
If the types really are not compatible, then the string names should
not match.
Maybe class should return "GF(2)" if it is GF(2), and octave can
pass the
extra info in the parentheses to the zeros constructor.
- Paul
Paul,
load/save is no problems, I just save which extension field of GF(2)
I'm in an the primitive polynominal, together with the class. Its
just another piece of information associated with the variable.
As for having class return all of the information on the type, I
really hope your kidding. The problem is then that there are a huge
number of different primitive polynomials available as we take larger
extension fields of GF(2). For example GF(2^15) has 1800 different
possible primitive polynomials. The problem is even worse for fixed
point types, where each element of a matrix can have a different
representation and each of those between 0 and 32 bits in the
representation of the integer and decimal parts of the elements.
The implication that class returns the full information to define the
type, is that there is a completely different type for all possible
galois fields and fixed point matrices. Even if there were seperate
types for each of the possibilities, imagine the number of
different versions of the operators I'd need to implement,
particularly for the fixed point types. In all practical senses this
is not feasible.
For the fixed point types, having different representations doesn't
make them incompatiable. All aritmetic operators can still be
performed. However the same can not be said for galois fields. So I
think for galois fields we just have to live with the return string
of class being the same for incompatiable galois fields...
I was assuming a string containing 'class(subclass)' where octave used
'class' to determine which type to invoke and the type used 'subclass'
to decide what to do. But no I'm not taking this idea very seriously.
Another alternative is to delay recording the primitive polynomial type
until something is actually assigned to the matrix, and from then on
check
that it is consistent. Would that work for you?
Err, I have to admit that you can do
gf(floor(8*rand(4,4)),8) + ones(4,4)
As the galois/matrix operations are already taken into account with the
matrix promoted the a galois field. However
a = zeros(4,4); a(:,1) = gf(floor(8*rand(4,1)),8)
won't promote a, but leave it as a matrix, and so the implementation of
triu won't work. I suppose an alternative for the galois fields is to
modify the assign function to promote the matrix to a galois field as
well... This might also work for the fixed point operators.
Or maybe something more generic, such as array(exemplar,dims) so that
dispatch will work. Also, this makes more sense for some types such
as 'cell' for which I was assuming the zeros function would create a
set of empty cells.
Then triu would be:
z = array(X,size(X));
for i=1:columns(X), z(1:i,:) = X(1:i,:); end
Otherwise, zeros(dims,'auto',exemplar) does do what we want assuming
the class registers a zeros constructor.
I don't see that we need an explicit zero constructor,
octave_value retval = args(0);
retval = retval.resize(dim_vector(0,0)).resize(args(0).dims());
does exactly the right.
Regards
David
--
David Bateman address@hidden
Motorola Labs - Paris +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
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], (continued)
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/23
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Paul Kienzle, 2005/02/23
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/24
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Paul Kienzle, 2005/02/24
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/24
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Paul Kienzle, 2005/02/24
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], David Bateman, 2005/02/24
- Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Paul Kienzle, 2005/02/24
- Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]], David Bateman, 2005/02/25
- Re: Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]], Paul Kienzle, 2005/02/25
- Re: Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]],
David Bateman <=
- Re: Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]], Paul Kienzle, 2005/02/25
- Re: Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]], John W. Eaton, 2005/02/25
- Re: Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]], David Bateman, 2005/02/25
- Re: Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]], John W. Eaton, 2005/02/25
- Re: Class of User Types [Was: Moving code from octave-forge to octave [Was: polyderiv problem?]], David Bateman, 2005/02/25
Re: Moving code from octave-forge to octave [Was: polyderiv problem?], Przemek Klosowski, 2005/02/10
Re: Moving code from octave-forge to octave [Was: polyderiv problem?], John W. Eaton, 2005/02/10
Moving code from octave-forge to octave [Was: polyderiv problem?], John W. Eaton, 2005/02/10