Martin Baker wrote:
>
> > I looked a bit at groupPresentation.spad. I must say that I
> > do not like "equality" there: normally in math one can
> > replace equal by equal, but "=" from GroupPresentation
> > returns true for quite different groups. The comment
> > is misleading: if you really mean isomorphism, then
> > the groups may be isomorphic even if "=" returns false.
> > And of course the groups may fail to be isomorphic
> > when it returns true. Also, for group presentations
> > we would rather use "identity mapping on generators
> > extends to isomorphism" than plain isomorphism.
>
> I wanted to implement SetCategory and so I needed some code for "=". The
> problem is that isomorphism is not computable and other forms of
> equality are not very useful.
Equality of representation is easy to compute and has some
(limited) use -- it seem to be most natural thing to satisfy
requirements of SetCategory.
One extra remark: you use name 'GroupPresentation' not
'FinitelyPresentedGroup'. For groups it is natural to
consider isomorphism, but for presentations natural
equality is just that of representations.
> I don't understand "identity mapping on generators extends to
> isomorphism"? Is this some level of equality that is both computable and
> useful for presentations? If so, where can I find out more?
It is uncomputable, but sometimes is more desirable than
isomorphism.
> > I also looked at 'genName'. Using character codes
> > here is bad style: it would be much better to
> > use indexing into a string to produce letters.
> > Your comment says that you want to skip over 'e'
> > (to reserve it as unit), but you also skip over
> > 'g'. Your code returns 'e' even if the 'suffix'
> > is nonzero, but IIUC you should produce letter
> > with suffic in such case. Loop at the beginning
> > is doing division with remainder, we have a
> > function for this. Something like
> >
> > (suffix, i) := divide(abs(i2), 25)
> >
> > should do. Since you skip over one letter the
> > correct divisor is 25.
>
> Yes I should not have made the code dependent on 'ASCII' code I will
> update that.
> This requirement to assign unique variable names must be a more general
> issue in mathematics code like FriCAS does something like that already
> exist in FriCAS SPAD? If not, should I implement it so that it is not
> specific to this particular domain?
Well, most domains use symbols as names and 'new()$Symbol' gives
you fresh symbol. There are also routines to print numbers is
various bases, they could be reused to produce names from
integers. But your requirement to avoid 'e' is somewhat unique.
Anyway, code like:
letters : String := "abcdfghijklmnopqrstuvwzyz"
letters(i + 1)
is an easy way to produce letter corresponding to i for i
between 0 and 24. For efficiency it is good to define
'letters' outside routines (so that the string is created
only once).
--
Waldek Hebisch
--
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 https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
