On Mon, Jan 9, 2012 at 9:17 AM, Waldek Hebisch wrote: > 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) >
Actually that is not tricky at all once you know that . has higher priority than function application. > 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. This paragraph would make a very useful comment in the source code. > So > > bname:=b.(0) > CatEval(bname) > > is a roundabout way of saying 'b'. > Yes, but Ralf reported this: >> > Interesting >> > >> > PrinAncb:= first(b).(4) >> > >> > gives >> > >> > with bootsys >> > (SETQ |PrinAncb| (CAR (ELT (|CatEval| |bname|) 4))) >> > >> > with depsys >> > (SPADLET |PrinAncb| (CAR (ELT (|CatEval| |bname|) 4))) In this result we do see '(|CatEval| |bname|)' not '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. > Sure 'b' works. You wrote 'b' but the result contains CatEval anyway. Why not just write what it is? >> 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. I am sorry that was as they say, a "thinko". What I should have said is that 'find_ffl' was eliminated. > Clearly you missed the point that CatEval(bname) is > a no-op. No I did not miss that even when first reading. I deduced that it seemed to behave that way in this case but without further analysis I could not be sure that this is always the case. Purpose there is some good reason that these categories are being re-evaluated? Perhaps there is some side-effect that necessitates it? > 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). > No, I had not reason to try to understand this. I agree that it is much simpler in the FriCAS version but I would be very difficult for me to prove that it is equivalent. There seems to be nothing immediately available in the source code or comments that suggests this simplification. Your knowledge of how this works is critical here. > 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'. Yes, this would be good although perhaps there is no need for a separate function? > 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. > In OpenAxiom 'find_ffl' has been eliminated (my earlier mistake). > 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 would propose that the explanation you have provided in this email should become comments in the source concerning 'JoinInner'. > >> 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 It is the purpose of accessors to high some details of the implementation in order to help ensure modularity. I am still not convinced that the change made in FriCAS is a good thing. > - 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. > I find this an odd conclusion. It is like saying that documentation interferes with understanding ... :( > 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, But tracking changes to names reflects exactly the history of functional changes that you mention above, no? Choosing a meaningful name is part of the documentation. > for example OpenAxiom has 'categoryAttributes' but > attributes are gone in FriCAS, so the name would be > misleading... > I think implementing attributes as categories is a separate issue. I am not against this change but although the impact on the code in the library is small, I think the change does deserve more discussion from the point of view of the semantics of the Spad language. In any case since attributes have been eliminated, of course there would be no need then of 'categoryAttributes'. Regards, Bill Page. -- 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.
