Slashdot Mirror

With python, the object is the way, the truth, and the light. Let no man cometh unto his data save through the object. In perl, OO is an option, not a requirement.

Hmm? You can quite happily store your data in interwoven dictionaries, lists, and tuples if you like, and never write a single class. If you want to talk about classes being a requirement, talk about Java.

With python, you cannot generate C code to compile into an a.out.

With python, the pattern matching is not tightly integrated into the language. It is merely loosely bolted on, which introduces inefficiencies and quoting clumsinesses.

True, but it also means you can leave it out if pattern matching isn't of interest to your application domain. People who want to run massive numeric simulations, build virtual environments, or run a large online role-playing game may not care about processing text. (Coincidences are funny things; while checking the third link, I went to reference.com and was startled when my search pulled up Python code on my screen -- someone forgot to make a CGI script executable, I suppose. reference.com is an application that does care about text searching, I would imagine.)

The greatest problems with regexes in Python 1.5 are:

1. Parts of re.py are still written in Python, not C, and are therefore slow. Fixing that is on my list for 1.6.
2. PCRE doesn't do a lot of optimizations and analyses. Mostly this is because the compiler doesn't build a parse tree and traverse it, but instead tries to construct a string of bytecodes in a single pass.
3. Unicode regexes are an open issue at this point. I've been casting longing glances at the regex engine in Mozilla, which does build a nice parse tree and supports Unicode, and hope to work on splitting it out into a separate library.

With python, you cannot determine your calling context, nor behave differently dependent upon the same.

With python, writing an eval string is a pain in the royal butt due to the insane whitespace problem.

With python, you have no equivalent to Apache's mod_perl.

One example of "open source" thinking in science is the increasing importance of preprints over journal publication. Traditional scientific communication relies on institutionally sponsored (commercial or nonprofit) journals publishing papers that have been carefully vetted by referees. But in many fields (including my own, astrophysics) this system has been almost completely supplanted in recent years by electronic distribution of unrefereed preprints through the server at http://xxx.lanl.gov/. The questions raised by this shift should sound familiar to open source software advocates. For example, how can quality of product be maintained in a system without identifiable, responsible publishers? My own experience suggests that quality is enhanced by widespread distribution of results before publication, for exactly the same reason that distribution of source results in better code: lots of eyes looking for bugs (or neglected references, etc.). Paul Ginsparg has written thoughtfully about these issues, for example at http://xxx.lanl.gov/blurb/pg96unesco.html .

One example of "open source" thinking in science is the increasing importance of preprints over journal publication. Traditional scientific communication relies on institutionally sponsored (commercial or nonprofit) journals publishing papers that have been carefully vetted by referees. But in many fields (including my own, astrophysics) this system has been almost completely supplanted in recent years by electronic distribution of unrefereed preprints through the server at http://xxx.lanl.gov/. The questions raised by this shift should sound familiar to open source software advocates. For example, how can quality of product be maintained in a system without identifiable, responsible publishers? My own experience suggests that quality is enhanced by widespread distribution of results before publication, for exactly the same reason that distribution of source results in better code: lots of eyes looking for bugs (or neglected references, etc.). Paul Ginsparg has written thoughtfully about these issues, for example at http://xxx.lanl.gov/blurb/pg96unesco.html .

This webpage has a tool that gives info similar to perfmon under NT. Under Intel, it uses the model specific registers (which report everything from cache misses to branch delays...) as implemented by the library libpperf.

This tool is IMHO the best of the pack out there at the time for really understanding the performance of your programs with respect to caching and processor quirks. Check it out.

This Digital Nervous Network is based on work by Mark Tilden as the article mentions. What wasn't really mentioned (aside from it being built from el-cheapo parts) is that there is a large hobbiest community who builds these things.

Essentially they're based on wiring an even number of inverting stages together. Normally this would settle on some ugly analog value that the gates really aren't designed to. By letting motors perturb the gates inputs via RC coupling the outputs of the gates will go into patterns of digital signals. In the proper conditions these signals can be amplified to drive motors in a walking type motion. Further perturbations change the gate of the walk etc.

The community is called BEAM robotics.

The problem is archiving. Ten, twenty, one hundred years down the line, we still need to be able to get at the document. Computers aren't good at that. (...) Opening a document that was created even two years ago can be an adventure -- imagine what that will be like in a century.

This is a very important point, and something that makes me nervous about the current trends in 'full text online' journal websites. My student subscription to the Biophysical Journal, to take an example, includes password access to the full text of the journal. Very nice, but I can't exactly cite it since it's not open access and may disappear (or re-arrange) at any time. I don't even get a CD out of the deal.

There are two obvious ways to approach this. Printing paper copies has already been mentioned, and this is certainly a good idea. The other is just to budget for data migration. University libraries and the publishing organization should both take responsibility for this. One has to plan on migrating data to new media once a decade anyway, and that might be a good time to translate the data format as well. I think the comment about two year old documents is a little specious. This is true of proprietary data formats, but not widely adopted open ones. It gets harder the older the format is, but the time constant is a little more manageable. Four year old html is still perfectly readable, and so is 10 year old TeX, to pick a more challenging example. Storing all that paper takes resources; data is no different.

Open distribution licenses would immediately help with alot of this as well. I think that's the only way citation of online resources would ever work--as some kind of meta-reference into a distributed archive, much like the eprint system now provides ( gr-qc/9905084). I've always found it rediculous that journals expect me to sign over the copyright to the articles I write.

Whatever happened to a review system for the eprint archives anyway?

The problem is archiving. Ten, twenty, one hundred years down the line, we still need to be able to get at the document. Computers aren't good at that. (...) Opening a document that was created even two years ago can be an adventure -- imagine what that will be like in a century.

This is a very important point, and something that makes me nervous about the current trends in 'full text online' journal websites. My student subscription to the Biophysical Journal, to take an example, includes password access to the full text of the journal. Very nice, but I can't exactly cite it since it's not open access and may disappear (or re-arrange) at any time. I don't even get a CD out of the deal.

There are two obvious ways to approach this. Printing paper copies has already been mentioned, and this is certainly a good idea. The other is just to budget for data migration. University libraries and the publishing organization should both take responsibility for this. One has to plan on migrating data to new media once a decade anyway, and that might be a good time to translate the data format as well. I think the comment about two year old documents is a little specious. This is true of proprietary data formats, but not widely adopted open ones. It gets harder the older the format is, but the time constant is a little more manageable. Four year old html is still perfectly readable, and so is 10 year old TeX, to pick a more challenging example. Storing all that paper takes resources; data is no different.

Open distribution licenses would immediately help with alot of this as well. I think that's the only way citation of online resources would ever work--as some kind of meta-reference into a distributed archive, much like the eprint system now provides ( gr-qc/9905084). I've always found it rediculous that journals expect me to sign over the copyright to the articles I write.

Whatever happened to a review system for the eprint archives anyway?

Biological Effects of Stellar Collapse Neutrinos article from the astro-ph archive

While this DX is quite different ( and more powerful), people might be interested to know about other Open Source visualisation software :

The General Mesh Viewer:

www-xdiv.lanl.gov/XCM/gmv/GMVHome.htm l

Maverik:

aig.cs.man.ac.uk/systems/Maverik/

If you're interested in quantum computation and cryptography you may be interested in checking out the Los Alamos site on quantum crypto.


Also some of you may be interested in Bruce Scheier's book Applied cryptography: Protocols, Algorithms, and Source Code in C, which was previously mentioned in other posts. You can find information on it at this Amazon.com link.

I might as well also give the link to a site on basic cryptology, called a "beginners page on cryptography" It may or may not help/interest readers.

On a side note, I really have enjoyed reading everyone's comments on this subject today. Hopefully these links don't come to late in the "day" for anyone to get good use out of them.

I think loyal slashdotters everywhere should remind the keepers of that web site of the existence of the Beowulf class supercomputer, don't you?

---

Just in case anyone was in a coma all last year and doesn't know what Avalon is, here's the link.

I wonder if the Avalon folks ever tried anything as trivial as Ray Tracing.

CIC3 at Los Alamos Labs has been doing this wavelet stuff for a long time. They have a demo online at:

This page is entitled Quantum Algebra, so you might find it interesting.

I have not spent any time there. I found it as a link from here.

SteveM

The authors of the ACM Classics recieved no compensation for their articles and letters to the editor. While ACM might have paid the peer reviewer of the article a small sum I doubt it. The ACM does not owe me anything, but I would rather in the future that authors just put their articles up on something like the e-print archive because I feel that the benefits of anyone being able to download computer-science articles without toll outweighs whatever benefits the ACM provides. So, yeah, I guess I agree that ACM does suck dick a lot of the time as far as I can tell.

Well, one acronym, actually: HIPPI.

Anyone have HIPPI devices on their PC? How about at work? Not very common, huh? Assuming SCSI survives and continues to evolve, it'll be the HIPPI of the next century, IMO. Here's what I base that on:

• FireWire will dominate the consumer market. I think it's pretty clear that FireWire will easily take over in the consumer market--all things (like OS support, M$ not seeing it as a threat to some facet of their business, etc.) being equal, of course. Consumers will eat up the tiny, simple cables, the hot-swapping, the single connector, the large device limits, the lack of IDs and termination, and so on. They don't want or need the highest of high-end speeds. Add to this the presence of FireWire in other consumer markets like DV and possibly audio equipment and it's a sure bet to appear on every home PC eventually.
• FireWire will probably dominate all but the very highest of the high-end. FireWire is "slow" now, but this is the very first generation of products. Did anyone doom SCSI to be stuck at the speed of SCSI-1 back when it was introduced? It stands to reason that FireWire will evolve just like SCSI did. Assuming SCSI development continues in some capacity after FireWire takes the consumer market, it may stay ahead of FireWire given its head-start in speed. But eventually SCSI is going to meet the same fate as any fast parallel interface (i.e. HIPPI), drowning in giant, expensive cables with very limited room to grow because of the basic design spec (device limits, termination, etc.). Maybe the NSA will use UltraMegaWideFast SCSI-7 in 2010, but you won't find a connector on the back of your Compaq from CompUSA. By that time, FireWire will probably be faster than the very fastest spinning magnetic media, and it'll be even more ubiquitous than SCSI is now (due to its penetration in the consumer audio/video market).
• SCSI's installed base only delays the inevitable, it doesn't prevent it. People and companies with big bucks invested in SCSI devices will continue to use them until they're forced to upgrade, but individuals will trade up even faster. I know I'm never buying another SCSI device again, and I own a handful of hard drives, removables, and even a CD-R I bought just a few months ago. And, like most individuals who own SCSI equipment, my drives are mostly older, slower devices, not fast, giant RAIDs or even single 10,000 rpm units. So even if I *wanted* to stick with SCSI, I'd have to have at least two interfaces on my computer: an older SCSI card for my slow devices, and a faster UltraSCSI card or somesuch for the fast drive(s), because mixing fast and slow devices on the same SCSI bus slows everything down (whoops, there's another advantage of FireWire: fast devices are not impaired by slow devices on the same bus).

Like any transition, it'll take time. Just look at how long it took for ISA to disappear! SCSI will march on in some form, but FireWire is clearly the future of the vast majority of the market (i.e. home and "normal" business users). It's my hope that the coming generations of the FireWire spec will surpass SCSI so even the high-end will get the benefits of serial interface simplicity. Now, about that analog video connector... ;-)