Kiki's Delivery Service is very good. On a sample of two girls (a 2-4 year old and her 14-16-year-old babysitter), it gets two thumbs up, again, and again and again (and I still like it after all those repetitions, too).
You could teach the CS classes on Macs. I've
got a Powerbook running OS X sitting next to me, with everything that I want on it -- Eclipse, for Java development, emacs, gcc, TeX, LaTeX, Perl, Apache, MySQL. I store projects in CVS on my ISP's computers, and the Mac is more than happy to do the extssh cvs thing to suck them down.
To an engineering approximation, it is Unix, and all the parts that are missing/different (all the configuration song and dance) were annoying anyway.
I lack the dogmatic certainty of my fellow EE, but I recall reading of the use of spread-spectrum techniques in satellite communication to allow ground stations to continue receiving signals as the satellite passed in front of the Sun. The Sun's a powerfully noisy transmitter.
"Finite number" arguments are uninteresting if you cannot put an upper bound on the finite number. Supposing the upper limit is a million transmitters per square mile. That's finite. Does it matter? In the field of computer science, probabilistic algorithms (analogous to spread spectrum) are extremely powerful, provided that you are willing to trade off absolute dogmatic certainty for a bet that is considerably better than your chance of not winning the big lottery jackpot.
The complaint spent some time on the subject of SCO's could-not-possibly-be-reproduced shared libraries, but then I saw no more mention of it.
Any idea what's up with that?
They'll also have an interesting time proving that their "trade secrets" are still secrets. There are many books on OS design now available that have been influenced by Unix over the years. If they're looking to demonstrate an actual infringement, they'll have better luck showing that IBM propagated a boneheaded mistake, rather than a Good Idea essential for high performance.
DSL is a sunk cost, till I start reselling my bandwidth to neighbors through a firewall.
The more correct price comparison is with a "single", whatever those are called nowadays. I recall that the price of N singles was much more than the cost of an album containing the same songs and B sides.
I also know that for a song that I really like ("The revolution will not be televised", Husker Du's version of "8 miles high", the EP Sharkey's Day with the longer Burroughs riff) I would cheerfully pay more than $.99.
As for figuring out what to buy, that's what college radio is for. You can't/. an FM broadcast.
The
Constructive reals package
by Hans
Boehm should work for you. It "sucks bits"
from subexpressions as necessary to obtain
the output precision that you ask for. Beware
of questions that take forever -- with
unlimited precision, certain (in)equality
questions can never be answered.
I wrote
some code
that uses this package to test the
quality of the Java Math.sin method,
if you would like a starting example.
Itanium's problems were visible from the moment the architecture appeared. It is, and was, an architecture that should excel at running Fortran programs, which are much more easily optimized than code written in C, C++, or Java. Compilers written ten years ago should be able to do a decent job compiling Fortran to Itanium with only a modest amount of porting work. Problem is, people aren't just running Fortran on Itanium.
The apparently-dynamic nature of current programs (that is, the intractability of statically analyzing them) has been coming for years. Ten years ago I spent my time studying the inner loops of SPEC benchmarks, and even then the typical inner loop of a C program was the instructions:
compare X with a value
branch out if equal
load indirect through Y to get Y'
load indirect through Y' to get X
branch to top of loop.
If Y (and Y', and Y'', etc) don't address memory in cache, you're hosed. Static prediction algorithms used in some of the first RISC chips (HP-PA, e.g.) work as well as any other on this loop, but you don't know that you're done until you load all the data and compare it. The loop cannot run any faster per iteration than the latency of the memory that happens to hold the data (Cache is King).
Object oriented programming, whether accomplished with an OO-TM programming language, or just a structure full of function pointers, is about the same can of worms (internally, the processor is caching the last location of the indirect branch, so it is not substantially different from prediction of conditional branches).
Slashdot Mirror
Kiki's Delivery Service is very good.
On a sample of two girls (a 2-4 year
old and her 14-16-year-old babysitter),
it gets two thumbs up, again, and again
and again (and I still like it after all
those repetitions, too).
You could teach the CS classes on Macs. I've got a Powerbook running OS X sitting next to me, with everything that I want on it -- Eclipse, for Java development, emacs, gcc, TeX, LaTeX, Perl, Apache, MySQL. I store projects in CVS on my ISP's computers, and the Mac is more than happy to do the extssh cvs thing to suck them down. To an engineering approximation, it is Unix, and all the parts that are missing/different (all the configuration song and dance) were annoying anyway.
I lack the dogmatic certainty of my fellow EE, but I recall reading of the use of spread-spectrum techniques in satellite communication to allow ground stations to continue receiving signals as the satellite passed in front of the Sun. The Sun's a powerfully noisy transmitter.
"Finite number" arguments are uninteresting if you cannot put an upper bound on the finite number. Supposing the upper limit is a million transmitters per square mile. That's finite. Does it matter? In the field of computer science, probabilistic algorithms (analogous to spread spectrum) are extremely powerful, provided that you are willing to trade off absolute dogmatic certainty for a bet that is considerably better than your chance of not winning the big lottery jackpot.
The complaint spent some time on the subject of SCO's could-not-possibly-be-reproduced shared libraries, but then I saw no more mention of it.
Any idea what's up with that?
They'll also have an interesting time proving that their "trade secrets" are still secrets. There are many books on OS design now available that have been influenced by Unix over the years. If they're looking to demonstrate an actual infringement, they'll have better luck showing that IBM propagated a boneheaded mistake, rather than a Good Idea essential for high performance.
Methanol != Ethanol
Ethanol's what's in vodka, methanol is poisonous.
DSL is a sunk cost, till I start reselling my bandwidth to neighbors through a firewall.
/. an FM broadcast.
The more correct price comparison is with a "single", whatever those are called nowadays. I recall that the price of N singles was much more than the cost of an album containing the same songs and B sides.
I also know that for a song that I really like ("The revolution will not be televised", Husker Du's version of "8 miles high", the EP Sharkey's Day with the longer Burroughs riff) I would cheerfully pay more than $.99.
As for figuring out what to buy, that's what college radio is for. You can't
I wrote some code that uses this package to test the quality of the Java Math.sin method, if you would like a starting example.
Itanium's problems were visible from the moment the architecture appeared. It is, and was, an architecture that should excel at running Fortran programs, which are much more easily optimized than code written in C, C++, or Java. Compilers written ten years ago should be able to do a decent job compiling Fortran to Itanium with only a modest amount of porting work. Problem is, people aren't just running Fortran on Itanium.
The apparently-dynamic nature of current programs (that is, the intractability of statically analyzing them) has been coming for years. Ten years ago I spent my time studying the inner loops of SPEC benchmarks, and even then the typical inner loop of a C program was the instructions:
compare X with a value
branch out if equal
load indirect through Y to get Y'
load indirect through Y' to get X
branch to top of loop.
If Y (and Y', and Y'', etc) don't address memory in cache, you're hosed. Static prediction algorithms used in some of the first RISC chips (HP-PA, e.g.) work as well as any other on this loop, but you don't know that you're done until you load all the data and compare it. The loop cannot run any faster per iteration than the latency of the memory that happens to hold the data (Cache is King).
Object oriented programming, whether accomplished with an OO-TM programming language, or just a structure full of function pointers, is about the same can of worms (internally, the processor is caching the last location of the indirect branch, so it is not substantially different from prediction of conditional branches).