Bill Page wrote:
>
> On Sat, Jan 7, 2012 at 11:38 AM, Waldek Hebisch wrote:
> > ...
> > I am a bit disappointed that after rewrite you find FriCAS
> > version so hard to understand. =A0Could you say what OpenAxiom
> > version easier to you? =A0Is it difference between:
> >
> > PrinAncb :=3D categoryPrincipals CatEval(bname,$e)
> >
> > and
> >
> > PrinAncb:=3D first(b).(4)
> >
> > (and similar places)?
> >
>
> My first difficulty started with Ralf's observation:
>
> On Thu, Jan 5, 2012 at 10:45 PM, Ralf Hemmecke <[email protected]> wrote:
> > ...
> > Interesting
> >
> > PrinAncb:= first(b).(4)
> >
> > gives
> >
...
>
> How is it possible that b can be replaced with '(|CatEval| |bname|)'
> ??? 'bname:=b.(0)' but it is just 'b' that is passed to 'first' ...
> Where is 'CatEval'? To find out I must study very carefully the
> function 'FindFundAncs'. For me this was very hard. As usual in Axiom
> code, the comments are not helpful and sometimes even misleading.
Actually, the only tricky thing is that the line should be:
PrinAncb := first(b.4)
Otherwise, here FriCAS is much simpler than original (and OpenAxiom).
Namely, b is binary representation of category (category vector).
b.0 is name of category. CatEval given name of categry produces
binary representation. So
bname:=b.(0)
CatEval(bname)
is a roundabout way of saying 'b'.
> I was very surprised when you admitted in another email in this chain
> that you had deliberately replaced the expression containing CatEval
> with just b. :(
Yes, why do all this back and forth conversions when using 'b'
just works.
> My second difficulty is to what is the significance of 'first(b).(4)'.
> I am asked to believe the comment:
> --Principal Ancestors of b
> but I do not know (yet) what is b. What is the structure of b? For
> this purpose the name 'b' alone is of no help.
>
> Both of these questions are easily answered from the OpenAxiom version
> of the code. Or at the very least I am reassured that the comment is
> indeed correct. Also in OpenAxiom the function ''FindFundAncs' has
> been eliminated and 'JoinInner' function has been simplified so that
> I have some confidence that I could really understand in detail of
> what JoinInner actually does. With the FriCAS version I find I am
> still uncertain.
Well, at least I still see 'FindFundAncs' in OpenAxiom. I am
not convinced that you really understand details of OpenAxiom
version. Clearly you missed the point that CatEval(bname) is
a no-op. Did you understand purpose of 'reallynew' and
machinations with 'resizeBuffer'? In fact the result of
this are unused and the machnations are pointless (and absent
from FriCAS version).
FYI, in FriCAS version in frist step we form list of categories
to join. At first one may think that we are already
given a list of categories (namely argumets to Join) and
there is nothing to do. But, unfortuanatly, for technical
reasons we need to add conditional ancestors of them.
This is similar in OpenAxion, but FriCAS version is
simpoler because there are no attributes in FriCAS
and FriCAS skips some optimizations here.
After that we need to find fundamental ancestors of join.
In FriCAS this is done by the 'find_ffl' routine. I admit,
the name is uninspiring. Probably the best name would
be FindFundAncs (or in full FindFundamentalAncestors)
but the name is taken by existing routine :(. I will
probably change name to 'JoinFundamentalAncestors'.
Anyway, given list of categories and conditions
'find_ffl' produces fundamental ancestors of the join.
BTW: 'find_ffl' and FindFundAncs are essentially doing
the same thing, but use different representation of
data.
After that FriCAS version forms union of list of
signatures -- for unconditianal part of join that
is strigthforward loop using SigListUnion. For
conditional members of join we need to adjust conditions, so the
loop is slightly more complicated.
> I am especially convinced that using accessor macros such as '
> categoryPrincipals' makes is easier to read the code without having to
> first memorize the basic Axiom data structures.
Yes, accessors with meaningful names help. However, note:
- accessors can hide some aspect of operation. In particular
they do not help to find simplifications made in FriCAS
version
- introducing accessors leads to a lot of textual change
without changing functionality. This makes tracing
history of functional changes harder.
- textual change interferes with other developement.
So developement cost of accessors is much higher then one
would think at first. And names which are good at one
point of time probably will be not so good in the future,
for example OpenAxiom has 'categoryAttributes' but
attributes are gone in FriCAS, so the name would be
misleading...
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
