> Way back then typical computers were a lot > smaller and fitting in Axiom in on other than "jumbo" ones was "fun".
Yes, it was. The reason the "compress" database exists was due to my work putting Axiom on a then very-new thing called a "laptop". It had to run under DJGPP on DOS with 4k of memory. Good times. Worthless now, of course. > So it is in effect a new project and if there is a non-existing Community > then their approval is moot and 100% unimportant. But not seeing all your > work preserved somewhere would feel criminal to me. History shows that certain ideas, such as proving computer algebra algorithms, are "ahead of their time". Eventually the LEAN proof crowd will need algorithms and the computer algebra crowd will need proofs so they will overlap. Future researchers will do this "as a matter of course" since they will have PhD students that need ideas to pursue. As for the "criminal" aspect, my code is "breadboard quality", meaning you need to know how CLOS works in great detail and how Axiom inheritance works and how to layer Lisp code expansion "all the way to the metal" and how the LEAN proof checker is implemented in Verilog for the FPGA paired with expanded RISC-V instructions. The code would be worthless to anyone else. I code to understand and then, having understood, rewrite it correctly (for now). The code is more like building a garden than a house. > That surely is because you did not have a full 1000 years to work on it > and not enough other like-minded folks chose to join in. Beyond the 1000 years you underestimate (:-) I am not smart enough to understand Bronstein and Trager's research enough to explain it. I just recently got a handle on Clifford algebras and how they differ from Grassman algebras. I am "quite slow", have a really bad memory, and take forever to learn. So my "literate explanations" of the Risch algorithm would likely be "not even wrong". I worked in robotics for years so explaining Denavit-Hartenberg matrices was easy as they have real physical meaning. > I already said that learning from what you are doing on types would be desirable. The key issue with dependent types is that you need to compute algebraic properties while constructing the type you need to compute your problem. My "canonical problem" is computing Unums[0] for doing limited arithmetic (witness the "configurable computing"[1] floating point effort in neural nets) as part of a type e.g. Matrix(Unum(8,3)) and whether the inversion algorithm should work in Unums or integers. The results differ. Even worse, I converted BLAS and LAPACK to common lisp and spent a lot of time pondering what Unums would mean for precision. The whole "computational mathematics" field is dense with hard problems. I am having a grand time being lost and confused but learning a lot. Fun times. Tim [0] End of Error Unum Computing https://www.amazon.com/End-Error-Computing-Chapman-Computational/dp/1482239868 [1] Configurable Computing for Floating Point https://arxiv.org/abs/2409.15073 On Thu, Feb 6, 2025 at 12:50 PM Arthur Norman <a...@cam.ac.uk> wrote: > On Thu, 6 Feb 2025, Tim Daly wrote: > > Arthur, > > I remember our conversations from the distant past. You did excellent > work > > making Axiom quite portable based on your lisp and other modifications. > > Thank you for the kind words! Way back then typical computers were a lot > smaller and fitting in Axiom in on other than "jumbo" ones was "fun". > > > Unfortunately I spent a lot of time with Bill Schelter and did work on > AKCL > > including various Axiom optimizations so I essentially removed all that > you > > did in order to work with what I knew. Sorry about that. > > No need to apologise. As your various emails explain your objectives were > veery specific and indeed ambitious. > > > I am really sorry to hear that Albert Rich died. We corresponded quite a > > bit. > > I co-authored a rule-based system at IBM Research based on Forgy's RETE > > as the basis for the Expert System offering. Rich and I discussed > improving > > the rule-based machinery in Axiom to include his work. He did amazing > work. > > > He is remembered!!!! > > > >> hypothetical keen new generation could cut their teeth on would be good. > > The "chance" you describe is a fork. We've already seen how that evolves. > > I think a form while a system is still alive is one thing. A fork when the > system is otherwise dead still needs to take some care to retain credit > for and memory of the earlier work, but it is much harder to say that it > is doing active damage. > > > The literate programming goal was to make it possible for someone to be > > able to maintain and modify Axiom without contact with the original > > developers. > > It was intended to "make Axiom live". The current sources build from the > > books (pamphlet format is just latex renamed). I collected a few > > research papers and got permission to re-create them in one of the > > books. > > Indeed but it is then fairly extreme to insist that the "someone" wishes > to make their modifications follow exactly the path that their > predecessors would have in an ideal world. > Well my interest might not be in recreating all of Axiom but in mining it > for ideas and components in a sense after the style where you collected > research papers authored by others to incorporate. It is way too long ago > that I looked inside Axiom but I suspect there is algorithmic content that > may do better than some existing alternative systems, and from a > practical person's perspective explositing those elsewhere would avoid > the work being lost if Axiom is not there to host it. In many respects > the type schemes and levels of abstraction that drove Axiom from early > days also needs not to fade from memory if the system dies. If in working > on that I ended up ready to adopt a more literate mode of work than I use > at present it would have educated me! > > > Unfortunately I only expanded certain algebra domains in literate form. > > I did insert bibliographic > > references in the algebra sources when I could find the papers. > > That surely is because you did not have a full 1000 years to work on it > and not enough other like-minded folks chose to join in. With Reduce I > find it really painful that the open source ideal that co-developers will > flock to join in work on an interesting projecy can be a bit of an > illusion! > > >> A "30 year horizon" surely involves a project being reinvented and > >> reforged anew > > > > It is not possible to do deep research such as adding proofs using > > the Axiom/SPAD combination. The parser/compiler is too fragile > > for such deep surgery. > Fair do. > > So relative to my "research focus" fricas > > is an effort devoted to "polishing". Worse I've introduced dependent > > types which really complicates the inheritance logic well beyond what > > the current compiler can handle. > I already said that learning from what you are doing on types would be > desirable. > > > The SANE version of Axiom is wildly different from the github version. > > For example, the source is now all pure common lisp using CLOS. > > It is also restructured from the ground up to include a LEAN Proof > > inheritance > > tower parallel to the Category-Domain towers. (I spent many years as a > > visiting > > scholar at CMU working with the CS and Math/Philosophy related to LEAN) > > > > So you can see that for the last decade I've drifted quite far from the > git > > repo. > > Worse, I've drifted from the SPAD world. Given that i was vilified for > > removing > > BOOT code I expect the non-existing Axiom community would not approve. > > Thus none of the code hit the repo. > > > So it is in effect a new project and if there is a non-existing Community > then their approval is moot and 100% unimportant. But not seeing all your > work preserved somewhere would feel criminal to me. > > >> So having a reasonably definitive "here lies" archive with at least > >> workable build scripts and pointers to the easier tasks that a > >> hypothetical keen new generation could cut their teel on would be good. > > > > The last tombstone above the current Axiom work is in git. > > There is also a tombstone on Wikipedia > > https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system) > > > Yes but the git version ignores all your more recent work that is really > pushing towards ideals. Your personal interest is not (as I understand > you) in delivering a working practical "software product" but in exploring > the more fundamental issues. It would be hard for anybody to pick that up > or even understand it if what you have been doing over recent years just > sits on your private machine to be eventuallyt lost forever. > > BTW I think my views regarding Microsoft and github and 2-factor > authentication may not be identical to yours but I am not terribly cheery > about all such. So for some of what I do for myself I host a git > repository on a Raspberry Pi (!) and a FEW selected people are given > access. And I control everything. > > Since I am now retired I do not need to satisfy anybody but myself with > how I spend my time - and I get my kicks more out of supporting other > users with bits of research (less deep and ambitious then yours) > interleaved. But also cooking and eating and wildlife activities... > > You say "code rot happens" and for any package unless there is some mut > who is prepared to patch stuff up the rot can be disabling for a whole > community. That is part of where I see myself fitting in! > > Arthur > > > The git repo built and ran tests without errors when last I checked (a > long > > time ago). > > It uses a known-good tar copy of Camm's Lisp which he has changed since > > then. > > The X11 replacement (Wayland) seems to be spreading rapidly but I don't > > know if > > Wayland will support Axiom's X11 code. Code rot happens. > > > > Most amusing is that Axiom runs on Windows :-) > > > > Tim > > > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3DJz8D8G1AgBf-D14ySVjSsja85_UtzDFQEsDvZG3oRd%3DQ%40mail.gmail.com.
