Re: [Axiom-developer] Units Package

[C Y]

--- William Sit <address@hidden> wrote:

> I learn a lot from the discussion with you (even though most of the
> ideas are "reinventing the wheel", there is always a positive side 
> to "reinventing" as compared to just "reimplementing"). 

I've always thought the best "reimplementers" are the ones who do
reinvent it because they tend to actually understand what they are
implementing, and it shows.

> So independent of what you want to do with
> the units project, you did not waste anyone's (certainly not my)
> time. 

Thanks!  I know it's been very educational for me, in fact in some ways
I wish I had done a lot of this before taking intro physics.

> On Fri, 4 Nov 2005 09:25:17 -0800 (PST) C Y wrote (Re: StepThrough)

> > 1)  Finish the draft of the "paper/documentation" part of the units
> > and dimensions package, so first Dr. Sit (if he has time) and then 
> > the general audience can judge the summary of the issues and 
> > features in question.  I am making progress on this but some of the
> > papers I need to review are taking time to digest.
> 
> I'm glad you are making progress, and I'll find time :-). But perhaps
> you can simply post the draft for everyone to comment on.  It would 
> be best when everything we say is in the open because we'll receive
> more constructive comments from others as well.

Sure, can do.  In fact, with the online pamphlet viewing now in place I
might actually be able to upload it for viewing that way.  (Of course
it's all LaTeX right now, but I don't think that will matter to the
system.)

> Contrary to what Martin suggests, I think it is a bad idea for you to
> work on two projects simultaneously. StepThrough is not a simple 
> issue (I'll comment on this if I can keep up with all the 
> discussions). 

Yes, I agree with you and Bill upon consideration.

> The coding for UnitsPackage is not as difficult as you think, 

<grin>  Glad to hear that :-).

> but you should actually take Bill Page's advice
> and simply dive in to get a feel for coding in Axiom (Spad). 

Sounds good.

> During all the rewriting (you sure will be doing that), you'll learn
> to become fluent in Spad (the compiler version). If you need help, 
> lots of people on this board will lend you a hand.

I really think the people on this list are one of the best assets Axiom
has.  So I'll take this chance to thank them collectively for helping
to make the Axiom experience so educational and exciting.

> On Fri, 4 Nov 2005 18:39:12 -0500, Tim Daly wrote (Re:StepThrough):
> 
> > > write down what you learn as you go in a tutorial form and we can
> > > add it as a section to volume 2, programming. it is always
> > > helpful to get a first-time user's view.
> 
> I agree with Tim. So indeed, if this is to become a tutorial for
> first-time user, who best qualifies than a first-time user recording
> all the steps for a non-trivial project? 

I'll do my best.

> Keep record of each trial, analyse each compiler error and
> note down how it is resolved. 

Time to dust off the old script command. :-)

> You will find that you have lots of ideas of how
> the compiler can be improved, and these suggestions will be valuable
> down the road when documentation for the compiler gets to a stage the
> developers can fix and modify it. If the whole thing becomes really 
> long, we can devote a whole volume to it. 

Hopefully we will be able to switch to Aldor to help with the compiler
situation, but that will probably be a while.

> There is no immediate need to "come to grips with the design and SPAD
> programming language of Axiom". When I first began coding in Axiom
> (the project was to compute first integrals of dynamical systems, 
> which was completed in less than a year in 1988, but unfortunately 
> the only surviving code is a piece of it for parametric linear 
> equations PLEQN -- I had the rest of the code, but they were broken 
> by changes in Spad; throughout the years, I had only time to keep
> PLEQN running as I moved onto other Spad projects),

Perhaps the rest could be retooled?  Or would that amount to a rewrite
in any case?

> I knew nothing
> about the design philosophy of Spad, nothing of Boot or Lisp, didn't
> know how to use Boot to debug erroneous code. There was no 
> documentation (the book was out only in 1992). I did have help from
> the original developers and I had to learn Groebner basis along the 
> way. So all it really took was some guts to go ahead. The less
> you know where the difficulties may lie, the better!

In that case I'm in good shape!  OK, here we go.

> As to pamphlet writing, I suggest you keep good notes first,
> concentrate on the coding and testing. When the code is kind of at a
> convenient break (say you have done a test version based on a small
> database of the SI system), get back to document this.

Heh - that's almost exactly the stage at which I stopped to try and
document the Maxima version.  

> Then move on to the next stage. If you start writing
> documentation of the code before you code, you may have to revise
> that a lot more often. Documentation of the design for a first
> implementation is another matter and you are right to do that 
> carefully, before coding.

Oh, I wasn't going to try to document code while still debugging,
except for recording the steps for the How to Start Writing in
Axiom/SPAD part.  
 
> Just another two cents.

I'd say it's worth a bit more than that!

Cheers,
CY



        
                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com