[Axiom-developer] bootstrapping (was: letting my mud settle)

[Bill Page]

On  November 9, 2005 9:17 AM C Y wrote:
> ...
> I'll hush up until I know enough to talk intelligently.
>

My old physics professor used to tell me that after graduation,
the more education you got, the more you realize the less you
actually know and the only point of "higher education" is to
learn how to ask better questions. And generally, I think your
questions are pretty good! ;) But of course there are diminishing
returns in any exchange.

> ...
> > > Chicken-egg situations are seldom desirable.
> > 
> 
> --- Bill Page wrote:
> 
> > Sigh. I feel like we have already been around this circle
> > several times... :) Well, I suppose it might be considered
> > a rather difficult concept, so it doesn't hurt to try to say
> > it all again another way ... see below. I hope you don't mind
> > that this email is a rather long as a result.
> 
> Sorry!  I don't mean to cause a rehash.  I'll go back and 
> look over the older discussions.
>

My comment was actually intended as a kind of pun. :o) But don't
apologize. If I sigh it is not because I think your question is
pointless; it is more likely because I think trying to answer
the question will be a little difficult. But those are the best
questions, not the worst.

> > ...
> > the analysis that I referred to below shows [one iteration
> > of the bootstrap] is not quite enough since some of the
> > dependencies do cycle back to affect code that has already
> > been compiled. However we believe (but have not proven!)
> > that this affects only some of the optimization that the Spad
> > compiler would have done and not that actual semantics of the
> > programs.
> 
> Hmm.  I take it at some point we should either demonstrate that
> or generate a binary using enough cycles so things iterate to
> steady state?
> 

I have already provided a script called 'fixed-point' that does
this. But it is not part of the default build because like I
said it takes three iterations to reach the fixed point (which
is a long time on most current desktop computers) and we are not
sure yet whether the changes from the first iteration to the last
are really significant. Probably it should become an optional
part of the build script.

For comparison purposed again, it might be interesting to note
that the gcc distribution has essentially the same kind of build
option that involves iteration and comparison of one iteration
of the gcc build to the next. In gcc it is assumed (maybe proven?)
that 3 iterations are always enough.

> > > > http://wiki.axiom-developer.org/17AlgebraBOOTSTRAPFixedPoint
> ...
> > > 
> > > Circular dependence is a feature?  I'm afraid I'm not
> > > following, if I understand you correctly - how can this be
> > > an advantage?
> > 
> > Yes it is an advantage - quite a major one. Of all of the
> > things that I have studied while learning about Axiom, this
> > is the one things about which I am still most excited. I
> > have to admit that I do not fully understand all of the
> > implications yet. But the idea is really very simple.
> 
> If you don't understand all the implications I'm most likely
> sunk, at least for a while :-).

Sometimes just trying to explain a problem helps one to
understand it better. So you see, you are already helping. :)

> 
> >
> > It turns out that unlike the case of the circularity in a
> > system of linear equations where using a guess and simply
> > repeating the calculation will not work very well, in most
> > (maybe all?) cases of circularity in the Axiom library, this
> > process does seem to lead to the exact and stable solution
> > after going 3 times around the loop, i.e. re-compiling all
> > of the Axiom library code three times, each time feeding the
> > bootstrap that results from the final stage of each cycle,
> > back into the start of the next cycle.
> 
> That's the kind of thing it would be nice to have a formal proof
> of :-).  Oh, well.  As long as it works.  It sounds a little
> like running LaTeX on a document multiple times to get to the
> final form.
>

I agree that a formal proof of convergence or at least some
idea about which situations lead to convergence and which do
not is very desirable. Yes, it is exactly like the case of
running LaTeX on a document multiple times to get the final
dvi file. In that case we can know from the structure of
the document what the maximum number of iterations will be
in any given situation.
 
> 
> Cheers, and thanks for taking the time to answer an
> essentially redundant question.
> 

I don't think the question is redundant (at least not yet :).
Thank you for asking.

Regards,
Bill Page.