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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
