Slashdot Mirror

How about getting some data from CERN?

They seem to have a couple of spare petabytes available. Just take part in the European DataGrid project and you'll have more than enough data.

The extent to which communication is a bottleneck in parallel processing depends strongly on the problem at hand and the algorithm used to tackle it. Some problems are amenable to batch processing (e.g. Seti@home), others require some level of boundary-synchonisation (simple fluid codes), others require synchronisation across all nodes (e.g. more complex plasma simulations)

For batch processing tasks, there isn't an issue. For the other's the loose synchronisation may be acceptable depending on the knock-on effect. Loosening the synchronisation obviously decreases the network and infrastructural burden on the job allowing the algorithm to scale better, but the effect of this has to be carefully studied.

This is important to the application developer, but is not particularly relevent to grids per-say. Grid activity, at the moment, is mainly towards developing code at a slightly lower level than application-dependant communication. It is already building up an infrastructure in which jobs can run which tries to remove any dependancy on a central machine. This is because having a central server is a design that doesn't scale well (and also introduces a single point-of-failure). The Globus toolkit provides a basic distributed environment for batch parallel processing, including a PKI-based Grid security system: GSI.

On top of this, several projects are developing extra functionality. For example, the DataGrid project is adding may component, such as automatic target selection, fabrication management (site management, fault tolerance, ...), data management (replica selection, management and optimisation, grid-based RDBMS), network monitoring infrastructure and so on.

The basic model is currently batch-processing, but this will be extended soon to include sub-jobs (both in parallel and with a dependency tree) and an abstract information communication system which could be used for intra-job communication (R-GMA).

The applications will need to be coded carefully to fully exploit the grid, and reducing network overhead is an important part of this, but The Grid isn't quite at that stage, yet. But we're close to having the software needed for people to just submit jobs to the grid, without caring who provides the computing resource, or the geographical location they'll run.

The extent to which communication is a bottleneck in parallel processing depends strongly on the problem at hand and the algorithm used to tackle it. Some problems are amenable to batch processing (e.g. Seti@home), others require some level of boundary-synchonisation (simple fluid codes), others require synchronisation across all nodes (e.g. more complex plasma simulations)

For batch processing tasks, there isn't an issue. For the other's the loose synchronisation may be acceptable depending on the knock-on effect. Loosening the synchronisation obviously decreases the network and infrastructural burden on the job allowing the algorithm to scale better, but the effect of this has to be carefully studied.

This is important to the application developer, but is not particularly relevent to grids per-say. Grid activity, at the moment, is mainly towards developing code at a slightly lower level than application-dependant communication. It is already building up an infrastructure in which jobs can run which tries to remove any dependancy on a central machine. This is because having a central server is a design that doesn't scale well (and also introduces a single point-of-failure). The Globus toolkit provides a basic distributed environment for batch parallel processing, including a PKI-based Grid security system: GSI.

On top of this, several projects are developing extra functionality. For example, the DataGrid project is adding may component, such as automatic target selection, fabrication management (site management, fault tolerance, ...), data management (replica selection, management and optimisation, grid-based RDBMS), network monitoring infrastructure and so on.

The basic model is currently batch-processing, but this will be extended soon to include sub-jobs (both in parallel and with a dependency tree) and an abstract information communication system which could be used for intra-job communication (R-GMA).

The applications will need to be coded carefully to fully exploit the grid, and reducing network overhead is an important part of this, but The Grid isn't quite at that stage, yet. But we're close to having the software needed for people to just submit jobs to the grid, without caring who provides the computing resource, or the geographical location they'll run.

The extent to which communication is a bottleneck in parallel processing depends strongly on the problem at hand and the algorithm used to tackle it. Some problems are amenable to batch processing (e.g. Seti@home), others require some level of boundary-synchonisation (simple fluid codes), others require synchronisation across all nodes (e.g. more complex plasma simulations)

For batch processing tasks, there isn't an issue. For the other's the loose synchronisation may be acceptable depending on the knock-on effect. Loosening the synchronisation obviously decreases the network and infrastructural burden on the job allowing the algorithm to scale better, but the effect of this has to be carefully studied.

This is important to the application developer, but is not particularly relevent to grids per-say. Grid activity, at the moment, is mainly towards developing code at a slightly lower level than application-dependant communication. It is already building up an infrastructure in which jobs can run which tries to remove any dependancy on a central machine. This is because having a central server is a design that doesn't scale well (and also introduces a single point-of-failure). The Globus toolkit provides a basic distributed environment for batch parallel processing, including a PKI-based Grid security system: GSI.

On top of this, several projects are developing extra functionality. For example, the DataGrid project is adding may component, such as automatic target selection, fabrication management (site management, fault tolerance, ...), data management (replica selection, management and optimisation, grid-based RDBMS), network monitoring infrastructure and so on.

The basic model is currently batch-processing, but this will be extended soon to include sub-jobs (both in parallel and with a dependency tree) and an abstract information communication system which could be used for intra-job communication (R-GMA).

The applications will need to be coded carefully to fully exploit the grid, and reducing network overhead is an important part of this, but The Grid isn't quite at that stage, yet. But we're close to having the software needed for people to just submit jobs to the grid, without caring who provides the computing resource, or the geographical location they'll run.

The extent to which communication is a bottleneck in parallel processing depends strongly on the problem at hand and the algorithm used to tackle it. Some problems are amenable to batch processing (e.g. Seti@home), others require some level of boundary-synchonisation (simple fluid codes), others require synchronisation across all nodes (e.g. more complex plasma simulations)

For batch processing tasks, there isn't an issue. For the other's the loose synchronisation may be acceptable depending on the knock-on effect. Loosening the synchronisation obviously decreases the network and infrastructural burden on the job allowing the algorithm to scale better, but the effect of this has to be carefully studied.

This is important to the application developer, but is not particularly relevent to grids per-say. Grid activity, at the moment, is mainly towards developing code at a slightly lower level than application-dependant communication. It is already building up an infrastructure in which jobs can run which tries to remove any dependancy on a central machine. This is because having a central server is a design that doesn't scale well (and also introduces a single point-of-failure). The Globus toolkit provides a basic distributed environment for batch parallel processing, including a PKI-based Grid security system: GSI.

On top of this, several projects are developing extra functionality. For example, the DataGrid project is adding may component, such as automatic target selection, fabrication management (site management, fault tolerance, ...), data management (replica selection, management and optimisation, grid-based RDBMS), network monitoring infrastructure and so on.

The basic model is currently batch-processing, but this will be extended soon to include sub-jobs (both in parallel and with a dependency tree) and an abstract information communication system which could be used for intra-job communication (R-GMA).

The applications will need to be coded carefully to fully exploit the grid, and reducing network overhead is an important part of this, but The Grid isn't quite at that stage, yet. But we're close to having the software needed for people to just submit jobs to the grid, without caring who provides the computing resource, or the geographical location they'll run.

The extent to which communication is a bottleneck in parallel processing depends strongly on the problem at hand and the algorithm used to tackle it. Some problems are amenable to batch processing (e.g. Seti@home), others require some level of boundary-synchonisation (simple fluid codes), others require synchronisation across all nodes (e.g. more complex plasma simulations)

For batch processing tasks, there isn't an issue. For the other's the loose synchronisation may be acceptable depending on the knock-on effect. Loosening the synchronisation obviously decreases the network and infrastructural burden on the job allowing the algorithm to scale better, but the effect of this has to be carefully studied.

This is important to the application developer, but is not particularly relevent to grids per-say. Grid activity, at the moment, is mainly towards developing code at a slightly lower level than application-dependant communication. It is already building up an infrastructure in which jobs can run which tries to remove any dependancy on a central machine. This is because having a central server is a design that doesn't scale well (and also introduces a single point-of-failure). The Globus toolkit provides a basic distributed environment for batch parallel processing, including a PKI-based Grid security system: GSI.

On top of this, several projects are developing extra functionality. For example, the DataGrid project is adding may component, such as automatic target selection, fabrication management (site management, fault tolerance, ...), data management (replica selection, management and optimisation, grid-based RDBMS), network monitoring infrastructure and so on.

The basic model is currently batch-processing, but this will be extended soon to include sub-jobs (both in parallel and with a dependency tree) and an abstract information communication system which could be used for intra-job communication (R-GMA).

The applications will need to be coded carefully to fully exploit the grid, and reducing network overhead is an important part of this, but The Grid isn't quite at that stage, yet. But we're close to having the software needed for people to just submit jobs to the grid, without caring who provides the computing resource, or the geographical location they'll run.

The extent to which communication is a bottleneck in parallel processing depends strongly on the problem at hand and the algorithm used to tackle it. Some problems are amenable to batch processing (e.g. Seti@home), others require some level of boundary-synchonisation (simple fluid codes), others require synchronisation across all nodes (e.g. more complex plasma simulations)

For batch processing tasks, there isn't an issue. For the other's the loose synchronisation may be acceptable depending on the knock-on effect. Loosening the synchronisation obviously decreases the network and infrastructural burden on the job allowing the algorithm to scale better, but the effect of this has to be carefully studied.

This is important to the application developer, but is not particularly relevent to grids per-say. Grid activity, at the moment, is mainly towards developing code at a slightly lower level than application-dependant communication. It is already building up an infrastructure in which jobs can run which tries to remove any dependancy on a central machine. This is because having a central server is a design that doesn't scale well (and also introduces a single point-of-failure). The Globus toolkit provides a basic distributed environment for batch parallel processing, including a PKI-based Grid security system: GSI.

On top of this, several projects are developing extra functionality. For example, the DataGrid project is adding may component, such as automatic target selection, fabrication management (site management, fault tolerance, ...), data management (replica selection, management and optimisation, grid-based RDBMS), network monitoring infrastructure and so on.

The basic model is currently batch-processing, but this will be extended soon to include sub-jobs (both in parallel and with a dependency tree) and an abstract information communication system which could be used for intra-job communication (R-GMA).

The applications will need to be coded carefully to fully exploit the grid, and reducing network overhead is an important part of this, but The Grid isn't quite at that stage, yet. But we're close to having the software needed for people to just submit jobs to the grid, without caring who provides the computing resource, or the geographical location they'll run.

Oh, wait, that's the Two Hours' Earlier's Slashdot Article. Some CERN folks built a sauna in the remains of a dead Saab. One of their problems was how to heat it; this seems like it should do just fine. That's the kind of synergy you get in the open-source movement....

here, here, and here.

CERN has also been trying to produce a quark/gluon plasma (and may have already done it).

Googling only turns up articles of questionable use. You can find better information in their list of experiments, and maybe a summary elsewhere on the CERN web site.

CERN has also been trying to produce a quark/gluon plasma (and may have already done it).

Googling only turns up articles of questionable use. You can find better information in their list of experiments, and maybe a summary elsewhere on the CERN web site.

I am relatively sure that the internet was first created by CERN (European Center for Nuclear Research) to exchange scientific data between different organizations. Proof here. Damn I proved myself wrong under closer inspection but I will post for the sake of spreading information. They invented the Web not the internet.

Since I goofed on the last post, I'll add the obligatory links to:

CERN
The Enrico Fermi Institute
Fermi National Accelerator Laboratories
Agronne National Laboratories
Los Alamos National Laboratories

Yep, all the information you could want on modern Quantum Physics.

Physicists are more than thinking about the Grid, I should know as they're funding my PhD in Data Grid Computing 8*).

The main reason for this is the Large Hadron Collider, which is due to go into production at CERN in about 2007. For the younger members of the audience, CERN was where Tim Berners-Lee developed the World Wide Web in the early 1990's

When it goes online it has 4 major experiments, each of which stores data at 100-400MB/sec, and I stress stores data at 100+ MB/sec, the first level is processing 40Terabytes a second. This equals a few petabytes a year (1PB = 1000TB = 1000000GB) which then has to be shipped to sites around Europe and the US.

All this is going to have data, processing and network requirements which make most techies gasp, i.e. Google only has a 20TB database, current physics ones are at 650TB+. At this level 14TFlops is kinda a cute little toy.

And yes, most of it's open source and based on the Globus Toolkit.

I'm surpirsed nobody mentioned CERN yet, a huge kick-ass particle accelerator among many things and the birthplace of the WWW by the way.
A must-see for any self-respected geek!

If you can afford the trip to Europe, I would recommend you visited the CERN particle ring. The largest facility is a 9 kilometer diameter ring located across the Swiss/French border. They use it to collide particles and create anti-matter. You'll get to see one of the finest display of technology to be found out there.
On a side note, there's a NeXT workstation in the entrance hall which was allegedly involved in creating the WWW.

If you can afford the trip to Europe, I would recommend you visited the CERN particle ring. The largest facility is a 9 kilometer diameter ring located across the Swiss/French border. They use it to collide particles and create anti-matter. You'll get to see one of the finest display of technology to be found out there.
On a side note, there's a NeXT workstation in the entrance hall which was allegedly involved in creating the WWW.

If you can afford the trip to Europe, I would recommend you visited the CERN particle ring. The largest facility is a 9 kilometer diameter ring located across the Swiss/French border. They use it to collide particles and create anti-matter. You'll get to see one of the finest display of technology to be found out there.
On a side note, there's a NeXT workstation in the entrance hall which was allegedly involved in creating the WWW.

First, antimatter "explosions" are actually fizzles, because P-barP reactions at rest tend generate neutral and charged pions and kaons, and neutrinos.

Neutrinos don't interact significantly with matter, so that energy is effectively lost. The neutral pions and kaons interact with the weak force only, and hence carry energy away for quite a distance (kilometers for pions) before they decay into something that does interact with matter. 50% of the time for every charge particle you get m neutral particles, where m>2 (see references

That means that most of your energy is carried kilometers or more away (for the relativistic ones) before decaying into energetic particles that DO cause things to go boom. The energy of the antimatter tends to be dispersed through a rather large volume.

Antimatter is, however, extremely valuable for rockets, due to a unique advantage. The general Hohman-transfer equation, which governs interplanetary flight, has a term exp{V/V0}, where V is the exhaust velocity and V0 is the "mission velocity", defined to be the delta v necessary to achieve a particular orbit.

For example, V0=11.2km/sec for orbit, and ~29km/sec for Saturn. Note that getting into Earth orbit gets you almost halfway to anywhere.

The propellant/load ratio, which is how much propellant per unit of mass you need to get somewhere, therefore depends (exponentially) upon the ratio of V/V0. Now, V is limited in chemical rockets to be at best 7.4 km/s for O1/LH2, so you have a built-in, exponentially growing ratio of rocket fuel you must carry per kilogram of payload. This makes manned flights to Saturn impractical with chemical rockets.

However, an antimatter rocket has no built-in limit on exhaust velocity. Solving the equations, that means that you can get to anywhere on an antimatter rocket with a fuel/payload ratio of 5:1. That doesn't sound great, but it's much better than 100:1 for orbit or 300:1 for interplanetary flights.

And, in fact, with antimatter rockets you can start *thinking* about not using Hohman transfers (which minimize the necessary energy) to get someplace, and can consider minimizing your time instead. You'll need the same fuel ratio, just more antimatter to increase your exhaust velocity V. Forward has a design for a basic antimatter rocket he did research on for the USAF.

Finally, there are ways to store antimatter for weeks at a time, using Pfenning traps and other magnetic facilities.

Antimatter, however, makes a lousy energy source, as it must be fabricated, you get less out of it than you put into it (we're currently .0000001% efficient, according to R.L. Forward's estimates) -- it's essentially an inefficient battery. For the same reason, antimatter is not a particularly good weapon. If you had an "antiproton" particle beam, 99.9% of the energy is coming from kinetic energy, and the inefficiency in handling/storing antiprotons isn't worth the measly 0.1% energy you get out.

But it's a wonderful rocket fuel.

--Adam

Can you use apostrophes in acronyms when pluralizing them? Some people say yes, some people say no. I say yes! Here's why:

Purdue University has a nice blurb on how to properly use apostrophes. One of the uses is "Forming plurals of letters, numbers, and symbols" to avoid confusion.

This page says you can us an apostrophe when the acronym ends in S to avoid confusion. Their example was if you said "The DHSSs of Europe are getting together next week" it would look strange so you can use "The DHSS's of Europe are getting together next week"

This says use an Apostrophe whenever there is punctuation in the acronym. Many other publications say you can't.

Since acronyms and codes are getting more popular they have to get more complex to be unique. You wouldn't want someone getting confused between multiple Non-Maskable Interrupts and a Navy Manpower Information System. Why not make it NMI's instead of NMIs so it doesn't get confused with a NMIS.

Many people seem to agree that you shouldn't use apostrophes to pluralize acronyms but I don't. I think the "ends in S" rule is good but what about the "could be confused with another acronym which is this one with an s on the end" rule. How do you know there isn't an acronym out there that is that one with an S on the end? How do you know there won't be one tomorrow?

You cant!

The bottom line is that the purpose of language is to communicate effectively. If I can do that using 31337 sp33ch then that's ok. It's like the whole stupid he/she vs they thing. (They has always been acceptable as a singular gender neutral pronoun despite many people's assertions otherwise).

To sum it up:

Language rules are here to help us communicate and any rule that restricts our ability to do so effectively is invalid by definition no matter how much some know-it-all wants to convince you otherwise. It's the way it always has been and the way it always will be.

That's a quote from the project's News page. They do indeed want to see if it falls up.

IMO, CERN's press release is much more informative than the BBC article.

But CERN's intranet is also readily searchable and apart from the technical details on the new LHC accelerator (which are publically available and make great geek reading) I also find
this further information on the AD (Antiproton Decelerator), which makes the trapping of antiparticles possible.

IMO, CERN's press release is much more informative than the BBC article.

But CERN's intranet is also readily searchable and apart from the technical details on the new LHC accelerator (which are publically available and make great geek reading) I also find
this further information on the AD (Antiproton Decelerator), which makes the trapping of antiparticles possible.

IMO, CERN's press release is much more informative than the BBC article.

But CERN's intranet is also readily searchable and apart from the technical details on the new LHC accelerator (which are publically available and make great geek reading) I also find
this further information on the AD (Antiproton Decelerator), which makes the trapping of antiparticles possible.

There's a reason.

From the horses mouth :-) Athena, the guys who did it
Nature.com article(PDF)
home page of the experiment

From the horses mouth :-) Athena, the guys who did it
Nature.com article(PDF)
home page of the experiment

From the horses mouth :-) Athena, the guys who did it
Nature.com article(PDF)
home page of the experiment

I've used IndigoStar's Perl2Exe for one 600-line CGI program that runs under FreeBSD. It works fine. The program I wrote provides a specialized form with lots of error-checking. Several people have access to the web site, including the customer's employees and all the employees of the web hosting provider. I didn't want someone changing or taking the code, so I wanted to compile the program.

De-Compile? I was told that it is difficult to decompile a Perl2Exe executable. I'm interested in hearing from anyone with experience with this.

Hide Perl Code? The HOT Ice "compiler" offers to obfuscate Perl code. Price: $3,995. As you might guess, I have no experience with this. Note that it does NOT compile the code.

You don't always want to give away your source code. How do you hide your Perl source code?

Other Perl Compilers? I'm very interested in hearing about other ways of compiling Perl programs. Perl2Exe is expensive, and tied to only one user. I've tried PerlCC and, as another comment poster said, was not able to get it to work. Apparently Perl2Exe is a cleaned-up version of a free Perl compiler. Is that correct?

Indy Singh is IndigoStar. Apparently the only person in the IndigoStar company is Indy Singh. He is friendly enough, but not always available for technical support. He sometimes hires help, I was told, but that person was not able to give tech support. I was told to wait two weeks until Indy Singh returned from vacation.

Philosophical question: On Slashdot it is politically correct to think that Perl is wonderful. However, it seems to me that every language should have both a compiler and interpreter. (CInt is a C/C++ interpreter.) Several years ago, Perl was a quick and dirty way of doing simple things. Now Perl is a big language with all of the problems of other big languages, but is lacking in some of the tools. (For example, check out Perl IDE. But, it is Windows only.) Perl debugging is primitive, too, it seems to me. I'd be interested in seeing an article that gives an overview of Perl debugging methods.

Wouldn't it have been better to put energy into a C interpreter, giving it the functions that are needed, rather than make a new language? Aren't some of the quick and dirty features of Perl now looking messy and dirty?

The speed of light is broken all the time. It causes Cherenkov Radiation...

http://rd11.web.cern.ch/RD11/rkb/PH14pp/node26.htm l

And yes, I know people usually mean the speed of light in a vacuum

Grid computing and clustering technologies are on opposite ends of the parallel computing scale.

Actually the clustering technologies are in the middle of the scale. Symmetric multiprocessing with shared memory is the most tightly coupled end of the scale, then come the clusters, then the Grid technologies at the other end.

Each calls for a different style of application development too. In systems where IPC is really expensive, you want to minimise it as much as possible. Not all apps that are written to run on a Beowulf cluster will necessarily port straight over to a grid framework. However, for apps that can be made to run well on a grid, the potential computing power available is far, far greater.

Yes, the development strategies are certainly different. However, often the Grid technologies can be used to provide a way to access the clusters instead of distributing the whole software on several machines. In that case you usually need only relatively small changes to existing software.

The benefit in this kind of approach can be that the authentication, authorization and encryption services for the connection and data transfer are provided by the Grid framework. For instance you can use the Globus Java CoG kit to authenticate in "Globus style" if you prefer that to the options Java natively offers. (Mobile Analyzer developed in our group at Helsinki Institute of Physics does that.)

Currently it is often still a bit unconvenient (mappings between Grid credentials and local user accounts etc.) but as these services develop users probably will have access to many more machines than they have now, because they don't need an account in each box. Then they can run their job (which is not necessarily parallel at all) where they like or run the job on their desktop but access data in an external database using their Grid account.

The computer or cluster for the job can also be selected automatically. The NorduGRID group has implemented this kind of system which connects several clusters in Nordic countries, they have a status monitor on on their website.

AJT

There's even a Newton Connection Utilities-like app for Unix/Unix-likes and OS/2 called Newtonlink. Unfortunately, it doesn't work out of the tarball on Debian (3.0, at least, which is the only release I have installed anywhere) and I haven't figured out why, yet.

Note to moderators: This is a serious question. You may disagree with what is said, but your disagreement does not make this question one that should be ignored. Please don't think that Larry Wall is fragile and needs to be shielded from confrontive questions. Note also that this question needs to be phrased in several ways to make its breadth fully clear.

Larry, now that you have seen what Perl has become after all the excellent work and all the years of effort, was Perl a good idea? Did we need another language? Would it have been better to have added features to an existing language, and to have made a more capable C++ interpreter, an advanced CInt, for example?

Now that Perl is a mature, full-featured language, do you think it is a properly designed language? When you first worked on Perl, did you imagine what it would eventually become? It was an easy language to learn then, and that was one of its advantages. Has Perl, now that it is mature, become just another language, with the exception that it is an interpreter? Are there any features of Perl that could not be added to C or C++? Are there features of Perl that were designed to make it easy, like implicit variables, that are not a good idea for a mature language? What are the features of Perl that make it a necessary addition to the numerous languages?

The web is not the same thing as the internet. The internet comprises the basic foundation, the most basic protocols (TCP/IP, etc). The web is the technologies that make websites possible (HTML, HTTP, etc). The web was created at CERN, the European nuclear research lab in Switzerland. You can find more information at the official information page here. Needless to say, that doesn't change anything. The idea for a strictly European internet is as silly as they come. Besides, Europe occasionally passes bad laws, too.

The www as any karma whore will tell you, was developed at CERN by Tim Berners-Lee.

Look at the growth of the internet over time and note the spike when the www appears. DARPA invented the internet, but the www made it.

ROOT is another option for visualisation (along with Octave and GNUPLOT). Interestingly, the ROOT system also includes a C++ interpreter (yes, interpreter!).

Fortran is still alive and well in the high energy physics (HEP) community... though it is fading away slowly (not as slowly as some people would like though). Up until very recently, FORTRAN was *THE* language for data analysis but is slowly being replaced by C++ in newer experiments such as BaBar at SLAC and is replacing FORTRAN for data analysis at a few older experiments such as H1 at DESY. The reason why FORTRAN is fading away so slowly is mainly because of CERNLIB which is a FORTRAN library that contains many useful functions (random numbers, matrix manipulation, data fitting etc...) As most particle physicists "grew up" using CERNLIB, it will be a while yet before FORTRAN well and truly disappears (in the HEP community anyway). Also of note, CERNLIB has now been released under the GPL, so anyone can use it. Nice.

You've got to be kidding - IDL is one of the worst things I've laid my eyes on.

I'm a physicist, and I had the displeasure of teaching poor first-year students IDL. It's beyond me why the course-planners decided on IDL - it teaches the students all the bad habits they shouldn't learn until after some 10+ years of programming in C :-)

Actually I know why the course planners chose IDL: they are astronomers, and as all real physicst knows, astronomers are a bit weird :-)

Again (yes I did another post on this topic), I'd like to direct your attention to ROOT, which has scripting and API capabilities. IDL lacks the latter, unless you pay $$$ to the IDL company to get them to write a module for you - heck making a n executable that uses IDL is a plain pain in the behind.

In essence - stay as far away from IDL as you possibly can. Use something you can extend and play with, and which has a decent executable speed.

I don't know if anyone mentioned ROOT yet, so here goes.

There's a framework from CERN called ROOT, which has a lot of nice features for numerical scientific computing.

The language is C++, but don't let that scare you - in time you will also frown upon procedual languages (they are hard to maintain) and functional languages (they just don't do the job for numerical stuff - to bad - I like the concept).

ROOT provides things like histograms, persistent object storage (and it beats Objectivity by miles!), and ladida. ROOT also has an interactive scripting environment, using C++. This is cool, as it means you can prototype your algorithms as scripts, and when your happy with them, you can simply compile them, and get much higher speeds.

Also note, that Intel's free C++ compiler is reputed to give a 30% increase in speed compared to GCC 3.0.

ROOT is used by some 70+ physics research projects around the world - from the gigantic Alice and STAR to the more modest Athena and BRAHMS.

If I were you, I'd defently consider C++ again. The stuff you've found on netlib is almost all outdated, and there's a good chance that it's been ported to C/C++.

I don't know if anyone mentioned ROOT yet, so here goes.

There's a framework from CERN called ROOT, which has a lot of nice features for numerical scientific computing.

The language is C++, but don't let that scare you - in time you will also frown upon procedual languages (they are hard to maintain) and functional languages (they just don't do the job for numerical stuff - to bad - I like the concept).

ROOT provides things like histograms, persistent object storage (and it beats Objectivity by miles!), and ladida. ROOT also has an interactive scripting environment, using C++. This is cool, as it means you can prototype your algorithms as scripts, and when your happy with them, you can simply compile them, and get much higher speeds.

Also note, that Intel's free C++ compiler is reputed to give a 30% increase in speed compared to GCC 3.0.

ROOT is used by some 70+ physics research projects around the world - from the gigantic Alice and STAR to the more modest Athena and BRAHMS.

If I were you, I'd defently consider C++ again. The stuff you've found on netlib is almost all outdated, and there's a good chance that it's been ported to C/C++.

I don't know if anyone mentioned ROOT yet, so here goes.

There's a framework from CERN called ROOT, which has a lot of nice features for numerical scientific computing.

The language is C++, but don't let that scare you - in time you will also frown upon procedual languages (they are hard to maintain) and functional languages (they just don't do the job for numerical stuff - to bad - I like the concept).

ROOT provides things like histograms, persistent object storage (and it beats Objectivity by miles!), and ladida. ROOT also has an interactive scripting environment, using C++. This is cool, as it means you can prototype your algorithms as scripts, and when your happy with them, you can simply compile them, and get much higher speeds.

Also note, that Intel's free C++ compiler is reputed to give a 30% increase in speed compared to GCC 3.0.

ROOT is used by some 70+ physics research projects around the world - from the gigantic Alice and STAR to the more modest Athena and BRAHMS.

If I were you, I'd defently consider C++ again. The stuff you've found on netlib is almost all outdated, and there's a good chance that it's been ported to C/C++.

I don't know if anyone mentioned ROOT yet, so here goes.

There's a framework from CERN called ROOT, which has a lot of nice features for numerical scientific computing.

The language is C++, but don't let that scare you - in time you will also frown upon procedual languages (they are hard to maintain) and functional languages (they just don't do the job for numerical stuff - to bad - I like the concept).

ROOT provides things like histograms, persistent object storage (and it beats Objectivity by miles!), and ladida. ROOT also has an interactive scripting environment, using C++. This is cool, as it means you can prototype your algorithms as scripts, and when your happy with them, you can simply compile them, and get much higher speeds.

Also note, that Intel's free C++ compiler is reputed to give a 30% increase in speed compared to GCC 3.0.

ROOT is used by some 70+ physics research projects around the world - from the gigantic Alice and STAR to the more modest Athena and BRAHMS.

If I were you, I'd defently consider C++ again. The stuff you've found on netlib is almost all outdated, and there's a good chance that it's been ported to C/C++.

I vote for high-performance Java, personally (with further extensions for better performance like lightweight objects [no inheritance but very little overhead for things like complex numbers], immortal [static] objects and a good generics implementation). I'd also like to see a very flexible and extensible operator overloading functionality, as well as the ability to use Unicode in Java source as an optional extension, for both variables and operators.

Also don't forget that gcc 3.x now includes a Java front end...perfect for extending into numerical Java. It's especially appropriate since it is a traditional "ahead of time" compiler permitting full optimization.

IBM has already provided matrix libraries written in Java with about 80% of the performance of fully optimized FORTRAN. Another interesting library is the Colt Library. It is also possible, using JNI and DirectIO, to use legacy libraries efficiently from Java where appropriate.

The focal point for numerical Java is Java Grande.

BTW, I was sorry to miss the Java 3 discussion yesterday, but this post summarizes my desires in that area. Quite a bit different from those of the article's author (what a whiner that guy was!).

At any rate, FORTRAN is still alive and kicking, and will be for another hundred years I'm sure... ;-)

I hope new development is mostly being done in Java in the not too distant future, though!

The web was invented at CERN, thats in Switzerland..
Everyone these days knows about the Internet and the World-Wide Web, but not everyone knows that the World-Wide Web was invented at CERN.
Where the quote comes from

• CERN management fabric, Jan 2001
• VA cluster manager for Intel boards with EMP
• Serial-to-network proxy
• Serial console howto
• Assorted switching gear

This is simply a fantastic experiment. The level of precision they have acheived is phenomenal, and they should all be commended for their efforts. The fact that the experiment was cancelled is a great tragedy. These kinds of experiments are a cheap way to look for new forms of matter. They won't tell you what the new matter is, but they will tell you it's there. They do this by very accurately measuring things that are easy to measure (like the muon's magnetic moment, or "g-2"), which are changed very slightly by the presence of new matter. The complimentary experiments are The Tevatron and The Large Hadron Collider which may be able to directly produce the new kinds of matter (if the new matter isn't too heavy) and thus identify it and study its properties.

From a theoretical point of view, it is very easy to "screw up" this measurement. That is to say, if you write down a new theory that has almost any kind of new matter, it gives a contribution to the muon's g-2. This is why there was so much excitement last year when they announced a deviation from the Standard Model. One must remember however that the community's accepted standard for a "discovery" is 5 standard deviations between the measurement and the prediction. The top quark discovery had more than 5 standard deviations signal over background. I cannot find numbers on their home page but it appears from their plot that their measurement is around 2 standard deviations.

Practically speaking, 2-standard deviation measurements pop up and then disappear all the time in physics. This is why we require the stringent "5-sigma" rule.

-- Bob

Like my post said, SQL is largely derived from SEQUEL, and the latter is the "more primitive predecessor" of the former; that's essentially the relationship you describe. And you're right about the reason for the name change (though the odd thing is that the conflict was with the name of an airplane -- IBM's lawyers must have been paranoid in those days). But we were discussing the name, and the pronunciation of the name. Check out the following document on the history of SQL:

• The 1995 SQL Reunion: People, Projects, and Politics

You'll note that the originators of SEQUEL/SQL are very careful to use one term or the other depending upon which point in time they're discussing. That the name change corresponded to some pretty significant additions to the language is probably why in circles outside of the creator's group SEQUEL and SQL are often treated as separate but related entities. But whether or not they are the same language misses the point: they are two different names, and as the above article shows, SQL was named in the style of other three-letter-languages of the era like APL (by "squeezing the vowels out of SEQUEL"), and was pronounced accordingly. This is why old farts (especially IBMers and ex-IBMers) are quick to correct whippersnappers who pronounce it SEE kwell.

-Ed

http://www.mandrakelinux.com/en/ftptmp/1024501320. d32fd091334bd166624816e3d84d319a.php#others

It looks like HP, Intel, and RedHat have been in the mix since 1999.

http://sverre.home.cern.ch/sverre/Linux_IA64_proje ct.html

Give CERN a try.

"10 years ago we gave a bunch of colleged kids arapnet, and we got the web."
I think you'll find the web started life at CERN.
Now, maybe I'm being pedantic, but I don't think they would apreciate being called "a bunch of colleged kids."