|From:||C Y <smustudent1@×××××.com>|
|Subject:||Re: [gentoo-science] Re: Scientific herd leadership|
|Date:||Mon, 22 Aug 2005 16:29:21|
|In Reply to:||Re: [gentoo-science] Re: Scientific herd leadership by "M. Edward (Ed) Borasky"
--- "M. Edward (Ed) Borasky" <znmeb@×××××××.net> wrote:> I used to be on the CMUCL and SBCL mailing lists because CMUCL is > tge best overall Lisp for my purposes and SBCL is the most actively > developed. In addition to Maxima, I use Lisp for algorithmic > composition, and right now CMUCL is the only one that fully supports > Rick Taube's Common Music.Cool! I didn't know Common Music was in active use. I should look at that more carefully.> I guess the fact that there are four "competing" open source Lisps > is a "problem", just as the fact that there are two competing open > source "emacs" packages is a "problem". Still, I think the various > compatibilities/standards/etc. between Maxima and the four > currently-existing Lisps are best suited by the current mechanism ...I guess it's a problem, but I like that there are so many different environments experimenting with different things. The biggest fly in the ointment right now is ANSI compatibility (*cough*gcl*cough*) - once an ANSI platform can be depended on on all 4 then people can start stretching the various features available on each, and maybe evolve what will become ANSI Common Lisp 2.0 :-) Maxima being able to run on all of them gives us a) a check that the underlying lisp isn't doing unexpected things to results b) assurance that if one lisp dies we have no trouble continuing on c) a good excuse to install lots of lisps ;-) and d) an extra way to shake bugs out of our code (not that we need any help right now, granted...)> they're all available in Portage in at least one "stable" form, > however ancient that might be, and available in "testing" > or "unstable" for us amateur beta testers. I don't have a problem > joining mailing lists for packages I use and filing bug reports > upstream -- ask the Texmacs, R, or Common Music and SBCL folks > about that. :)My main complaint is that, in many cases, the newer release of the lisp/CAS/scientific program in general is likely to contain many fixes, and in fact be more desirable to use generally than the older version. In fact, keeping the older, incorrect version around is an active disservice to people using it thinking it's correct. Perhaps in the case of the various lisps I can see waiting a bit (except for gcl ;-) but in the case of Maxima, when we DO put out a new release there tend to be fixes for mathematically incorrect behavior and other things that make no sense to wait on. It is improbable that Maxima will regress between versions - there's too much room for improvement. I would expect the same would hold for Axiom. Even if there WERE regression, it might not be caught for quite some time, since exercising the capabilities of a CAS is not trivial in and of itself.> Gentoo is about choice, right? If the choice, however, must be > where to allocate finite (or in some cases zero) volunteer > developer/maintainer time, I'd cast my vote for CMUCL as the Lisp > of choice, at least until SBCL hits 1.0 and gets the callback thing > worked out for Common Music.I would tend to agree, except I don't know how CMUCL does on non-x86 platforms. Clisp at least tends to run on ANYTHING, despite it's not being the performance choice. IIRC that's why Clisp was originally set as the no-choice-given default for Maxima, although that may have changed since.> GCL is a tad faster on some benchmarks, and CLISP has "readline" > built in.GCL can use readline too, at this point - not sure if it's in the ebuild by default. Oh, I recommend rlwrap for cmucl, by the way - assuming one is being foolish like me and not using SLIME ;-). Must learn SLIME, must learn SLIME...> I'm not sure there's a "stable" Axiom in the minds of the upstream > people just yet.Hmm, good question.> I had Axiom on my Debian systems when I was running Debian but > never had a chance to play with it. It takes several hours to > build from source on a fast machine.Yep - reminds me of acl2's build, or to a lesser extent brl-cad's :-). All the good stuff takes forever to build ;-).> I've forgotten what the core symbol crunching engine is -- IIRC it > carries an older version of one of the four open-source Lisps.GCL, although of late they have been staying relatively current.> In any event, I'll join the chorus of "let's have as much support > for Axiom as we can.":-) [snip - interesting about Octave vs. R - maybe the Octave interface should be bolted onto the R core!]> I don't know what brl-cad and acl2 are/do, so I can't help you there.Acl2 is... well, here's their own description: "ACL2 is both a programming language in which you can model computer systems and a tool to help you prove properties of those models." http://www.cs.utexas.edu/users/moore/acl2/ Here's one of its more famous uses: "Remember the Intel FDIV bug? The first Pentium [trademark, Intel, Inc] could not divide floating-point numbers correctly and it reportedly cost Intel $500 million to fix. At the time that was happening, we used ACL2 to verify that the floating point division microcode on AMD's competing microprocessor, the AMD-K5, was correct. AMD used ACL2 to verify the elementary floating-point operations for the recently released Athlon." This and HOL4 would be my first two candidates for proof systems to create ebuilds for. I took the bugzilla one for 2.8 and tried it on 2.9 (the current version) - it seemed to build successfully, although I've not done any fancy testing with it yet. BRL-CAD (http://brlcad.org/) BRL stands for Ballistic Research Laboratory - this is a powerful constructive solid geometry (CSG) modeling package used by the army for decades to do real world simulation. It was recently released as open source software, and it has the potential to plug a major gap in the lineup of open source software solutions. Unfortunately, it's history is so long that it predates Linux and the library naming conventions that go with it, and uses tweaked versions of other standard libraries. The result is that an improper install will wreck havock on an unsuspecting Gentoo box :-/. I ultimately had to reinstall. What it needs is to have all relevant libraries in their own directory (say /usr/lib/brlcad/) and go from there, but I don't know how to make an ebuild that a) builds it with those targets and b) updates the system correctly so brl-cad doesn't try to use the wrong libraries (e.g. in /usr/lib) or not know about the ones in /usr/lib/brlcad. I'm a bit like you - I love to tinker. The odds I'll do any serious CAD work with BRL-CAD are remote, but I like the idea of it being available in case I DO hit something that makes it necessary/worthwhile to put in the time. So if you've got the itch, I recommend BRL-CAD :-). (incidently, the main interaction environment is not called brlcad - it's something I forget at the moment. But if typing brlcad doesn't do anything it's not unexpected.)> Where *I* would focus "gentoo-science" -- indeed, all of Gentoo -- > is on packages that are vibrant, alive and even chaotic upstream. > Right now, that's R, Maxima, SBCL, Axiom, Ruby/Rails, Xen, TeXmacs, > NS/NAM, etc. > > ... the stuff that's on *my* hard drive. :)You definitely want to check out BRL-CAD - it's still actively used by quite a few people, IIRC. The project lead is Sean Morrison - very helpful guy. Even if you don't do CAD, worth a look as a potential assist to open source in general :-). I always make sure I've got Blender installed for the same reasons (or non-reasons :-P) even though you can fit my artistic talent in the head of a pin :-/. Cheers, CY ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs -- firstname.lastname@example.org mailing list