Bill Page wrote:
>
> 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:
> >>
> > So
> >
> > bname:= b.(0)
> > CatEval(bname)
> >
> > is a roundabout way of saying 'b'.
> >
>
> Yes, but Ralf reported this:
>
> >> > Interesting
> >> >
> >> > PrinAncb:=3D 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 do not know how Ralf gets this. I see:
)boot PrinAncb := first(b).(4)
(EVAL-WHEN (EVAL LOAD) (SETQ |PrinAncb| (CAR (ELT |b| 4))))
and the same in generated 'category.clisp' file. 'CatEval'
was in old version:
PrinAncb := first (CatEval bname).(4)
>
> >> 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.0 :(
> >
> > 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?
No, now we just have 'b'.
> >> My second difficulty is to what is the significance of 'first(b).(4)'.
> >> I am asked to believe the comment:
> >> =A0 --Principal Ancestors of b
> >> but I do not know (yet) what is b. What is the structure of b? =A0For
> >> 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. =A0Also in OpenAxiom the function ''FindFundAncs' has
> >> been eliminated and =A0'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. =A0I 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.
>
> > =A0Clearly 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?
Ok, in FriCAS you are saved such questions.
> >=A0Did you understand purpose of 'reallynew' and
> > machinations with 'resizeBuffer'? =A0In 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.
To notice that one can get rid of this requires effort. But
once it is removed understanding source is easier. In fact,
when working on JoinInner at first I was worried that numbers
produced in this part will change and that this may break
something. But analyzing effect of change showed that
numbers are not used at all. So what I did saves this
effort form persons trying to work with FriCAS sources.
> > FYI, in FriCAS version in frist step we form list of categories
> > to join. =A0At first one may think that we are already
> > given a list of categories (namely argumets to Join) and
> > there is nothing to do. =A0But, 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. =A0I admit,
> > the name is uninspiring. =A0Probably the best name would
> > be FindFundAncs (or in full FindFundamentalAncestors)
> > but the name is taken by existing routine :(. =A0I will
> > probably change name to 'JoinFundamentalAncestors'.
>
> Yes, this would be good although perhaps there is no need for a
> separate function?
Separate function makes clear that computations are used
only for their result and no variables (except
for FundamentalAncestors to which we assign the result)
in JoinInner are changed. In other words instead of
one big piece where potentially all things may interact
we have two almost independent parts. For me it is
much clearer.
> > 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).
No, 'find_ffl' was never in OpenAxiom. It was introduced
in FriCAS.
> >
> >> 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. =A0However, note:
> >
> > - accessors can hide some aspect of operation. =A0In particular
> > =A0they do not help to find simplifications made in FriCAS
> > =A0version
>
> 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.
To make things clear: in FriCAS I did not eliminate accessors.
In fact, even though FriCAS JoinInner is significantly
changed, still most lines come from original.
The changes eliminate useless computations (for example,
unnecessary CatEval took measurable time).
> > - introducing accessors leads to a lot of textual change
> > =A0without changing functionality. =A0This makes tracing
> > =A0history 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 ... :(
What is odd about this:
1) In FriCAS I can take a name and typically I will find it
in old versions. This speeds up checking history.
2) Volume of changes is _much_ smaller.
3) Have you never met situation where you have "almost ready"
patch, but then you need to do something else and when
you come back to the patch you see that it no longer
applies?
>
> > So developement cost of accessors is much higher then one
> > would think at first. =A0And 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?
In my linguo renaming is not a functional change.
> 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'.
My point is that corresponding entry in domain vector is still
there. It contains conditional categories (the same holds for
original and OpenAxiom). The only thing which changed is
the there are no attributes in this field, but we still need
an accessor.
--
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.
