axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: [fricas-devel] Re: RectangularMatrixCategory shoul


From: Martin Rubey
Subject: [Axiom-developer] Re: [fricas-devel] Re: RectangularMatrixCategory should have Finite
Date: 14 Dec 2007 13:12:04 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Martin Rubey <address@hidden> writes:

> Dear Waldek,
> 
> Martin Rubey <address@hidden> writes:
> 
> > Waldek Hebisch <address@hidden> writes:
> > 
> > > This is issue 258.  I plan to apply the patch below to solve the issue (as
> > > suggested in the issue we modify RectangularMatrixCategory):
> > 
> > Well, you'd also have to provide 
> > 
> > size() == (size()$R)^(m*n)
> > 
> > random() == matrix [[random()$R for i in 1..m] for j in 1..n]
> > 
> > lookup: % -> PositiveInteger
> >   ++ lookup(x) returns a positive integer such that
> >   ++ \spad{x = index lookup x}.
> > 
> > lookup mat ==
> >     s := size()$R
> >     pow := 1
> >     l := listOfLists(mat)
> >     res := 0
> >     for r in l repeat
> >         for c in r repeat
> >             res := res + index(c)$R*pow
> >             pow := pow*s
> >     res
> > 
> > 
> > index: PositiveInteger -> %
> >   ++ index(i) takes a positive integer i less than or equal
> >   ++ to \spad{size()} and
> >   ++ returns the \spad{i}-th element of the set. This operation
> >   ++ establishs a bijection
> >   ++ between the elements of the finite set and \spad{1..size()}.
> > 
> > index i ==
> >     quotients and remainders...
>  
> 
> I just checked: we should really implement these things in HOAGG S, if % has
> finiteAggregate.

My mistake.  finiteAggregate does not mean that all members have the same size,
only that they are all finite.  Eg., List has finiteAggregate.

Should we create another attribute, say, constantSizeAggregate, that says that
each element has the same number of members?  Furthermore, shouldn't
finiteAggregate and constantSizeAggregate rather be categories?  That would
make a lot of things cleaner.

Although, I would then also need a way to construct an element given a list of
its parts.  I vaguely remember that Bill already suggested this.  Back then, I
think, we concluded "no", since there is (of course) no canonical way to do
that...

Comments welcome,

Martin





reply via email to

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