Hi,
> I am thinking about this. I am a bit worried because > if we would like another form of indexong number of > combinations may get large. That is of course true. > So I consider alternative > of sort > > LSI => List Segment Integer > IndexType .... > autoCoerce(LSI) -> % > -- maybe just coerce, would need to experiment to find > -- out which one gives better behaviour > autoCoerce(SI) -> % > -- maybe other variants > convert : (%, Integer, Integer) -> LSI > -- extra arguments to represent lower and upper bound > -- for matrix indices, needed if we want complement > and then define > > > elt : (%, Integer, IndexType) > elt : (%, IndexType, Integer) > elt : (IndexType, Integer) To some larger part I like this approach. We could port that to other indexable structures not just matrices. (At least vectors should work too.) Can we maybe even get rid of Integer? Integers should then be coerced to IndexType things. > The idea is that interpreter/compiler magic should convert > what needed to IndexType. I am special casing Integer as > oterwise we would get mismatch with normal array indexing. Hmm. Why would it not work if we index Objects *only* by IndexType elements and Integers are (can be coerced to) that Domain? > It may require tweaking interpreter priorities for choosing > operations. Ok. To make the other point, the code I was talking about is complete and works by now. This unified approach seems to be superior and better from the software design view, but does not exist yet. Therefore I'd still vote for inclusion and improve later if we like. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
