Re: [Axiom-developer] Units Package

[William Sit]

On Wed, 2 Nov 2005 06:59:28 -0800 (PST) C Y wrote (Re: StepThrough)
> > > Well, once I get the units package figured out (if I ever do...
> > > grumble...)

> --- Martin Rubey <address@hidden> wrote: 
> > you reallly should.
> 
> I intend to.  I'm still reading papers and looking over other systems
> out there - I'm going to try my best to do this right.  Hopefully in
> another week or so I'll have something I can send Dr. Sit without
> feeling like I'd be wasting his time.

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"). So independent of what you want to do with
the units project, you did not waste anyone's (certainly not my) time. 


On Fri, 4 Nov 2005 09:25:17 -0800 (PST) C Y wrote (Re: StepThrough)
> --- Martin Rubey <address@hidden> wrote:
> 
> > Dear Bill, Cliff,
> >
> > Clifford, are you still there? I'm not quite sure about your status
> > now, are you interested in pursuing this project?
> 
> I am, but probably not immediately - I'm working again on the units
> package concepts so that will take some time.  My current thought is:
> 
> 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.

> 2)  While demolition of 1) is proceeding, I'll dive into the
> StepThrough issue, which will also be the time when I will really have
> to come to grips with the design and SPAD programming language of
> Axiom.  StepThrough is an excellent start because it should be
> informative, useful, but still relatively elementary (famous last
> words).  I think it's the usual thing - driving isn't so bad once you
> know how to drive, and in Axiom's case I need to learn how to drive.

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). The coding for UnitsPackage is
not as difficult as you think, but you should actually take Bill Page's advice
and simply dive in to get a feel for coding in Axiom (Spad). 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.

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? Keep record of each trial, analyse each compiler error and
note down how it is resolved. 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. 

> 3)  If by some chance any significant part of the units draft survives
> review the process of 1), I'll proceed to implement the actual SPAD (or
> maybe Aldor depending on the prospects of being able to use it in
> Axiom) required to bring it into being.  2) will hopefully supply me
> with the Axiom specific tools and knowledge needed to do this
> intelligently.

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), 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!

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. 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.

Just another two cents.

William