It turns out that the big problem is a bug - large objects don't work right, due to a roundoff problem. If you limit all objects, including the ground, to 50 meters in the longest dimension, they work better.
The total compensation (including fringe benefits) for each of the top five employees of a publicly held company has to be reported to the SEC.
The shareholders should set that amount. You put a number on the proxy, and the share-weighted median of those values is the limit on total compensation for the top five. Management should
be allowed to suggest an amount on the proxy, but that shouldn't be the default for unreturned votes.
Now that would make management more responsive.
For mutual funds and retirement plans, the right to set that value has to pass through to the beneficial owners. For a mutual fund, you'd specify a number on the fund's proxy, and the fund's managers would be allowed to specify the compensation limit for each company, but those choices would have to add up in some weighted way to the median of the value set by the real owners, the fundholders.
Gee, I had my Slashdot article on the SGI bankruptcy rejected back on May 8th when it actually happened. Two months later, the bankruptcy gets a mention on Slashdot.
SGI's main remaining business is real estate. They own many buildings in Mountain View, most of which they lease to Google.
Due to some bad decisions (like signing up for a 55-year land lease in 1995) SGI loses money on that deal. Then they tried a sale/leaseback deal with Goldman Sachs and dug themselves a bigger hole by locking in their rent at the top of the dot-com boom. A friend at Google says that SGI is a "great landlord", though.
SGI doesn't really have much left in the way of manufacturing facilities. The only thing left is Chippewa Falls, the old Cray facility. They had 1,858 employees left at the start of the bankruptcy. SGI had way too much legacy administrative overhead. They had 18 different corporate entities, from Cray to MIPS to Parallel to Alias/Wavefront, and 43 more marketing subsidiaries in various countries. Most of those organizations will disappear in the bankruptcy.
From the filing:
In the last several years, SGI has faced a number of challenges, which, taken
together, have had a negative impact on SGI's overall financial performance. In the late 1990's,
SGI made a series of investments in strategies and technologies that yielded less than the
expected results.
Er, right.
Realistically, what happened is that SGI was totally unable to cope with their high-margin business becoming a low-margin business. Few companies succeed at that transition, IBM being a notable exception. And even IBM finally bailed out of PCs.
With medium-level languages like C, some of the language constructs are lower-level than the machine hardware. Thus, a decent compiler has to figure out what the user's code is doing and generate the appropriate instructions. The classic example is
char tab1[100], tab2[100];
int i = 100;
char* p1 = &tab1; char* p2 = &tab2;
while (i--) *p2++ = *p1++;
Two decades ago, C programmers who knew that idiom thought they were cool. In the PDP-11 era, with the non-optimizing compilers that came with UNIX, that was actually useful. The "*p2++ = *p1++;" explicitly told the compiler to generate auto-increment instructions, and considerably shortened the loop over a similar loop written with subscripts. By the late 1980s and 1990s, it didn't matter. Both GCC and the Microsoft compilers were smart enough to hoist subscript arithmetic out of loops, and writing that loop with subscripts generated the same code as with pointers. Today, if you write that loop, most compilers for x86 machines will generate a single MOV instruction for the copy. The compiler has to actually figure out what the programmer intended and rewrite the code. This is non-trivial. In some ways, C makes it more difficult, because it's harder for the compiler to figure out the intent of a C program than a FORTRAN or Pascal program. In C, there are more ways that code can do something wierd, and the compiler must make sure that the wierd cases aren't happening before optimizing.
The next big obstacle to optimization is the "dumb linker" assumption. UNIX has a tradition of dumb linkers, dating back to the PDP-11 linker, which was written in assembler with very few comments. The linker sees the entire program, but, with most object formats, can't do much to it other than throw out unreachable code. This, combined with the usual approach to separate compilation, inhibits many useful optimizations. When code calls a function in another compilation unit, the caller has to assume near-unlimited side effects from the call. This blocks many optimizations. In numerical work, it's a serious problem when the compiler can't tell, say, that "cos(x)" has no side effects. In C, it doesn't; in FORTRAN, it does, which is why some heavy numerical work is still done in FORTRAN. The compiler usually doesn't know that "cos" is a pure function; that is, x == y implies cos(x) = cos(y). This is enough of a performance issue that GCC has some cheats to get around it; look up "mathinline.h". But that doesn't help when you call some one-line function in another compilation unit from inside an inner loop.
C++ has "inline" to help with this problem. The real win with "inline" is not eliminating the call overhead; it's the ability for the optimizers to see what's going on. But really, what should be happening is that the compiler should check each compilation unit and output not machine code, but something like a parse tree. The heavy optimization should be done at link time, when more of the program is visible. There have been some experimental systems that did this, but it remains rare. "Just in time" systems like Java have been more popular. (Java's just-in-time approach is amusing. It was put in because the goal was to support applets in browsers. (Remember applets?) Now that Java is mostly a server-side language, the JIT feature isn't really all that valuable, and all of Java's "packaging" machinery takes up more time than a hard compile would.)
The next step up is to feed performance data from execution back into the compilation process. Some of Intel's embedded system compilers do this. It's most useful for machines where out of line control flow has high costs, and the CPU doesn't have good branch prediction hardware. For modern x86 machines, it's not a big win. For the Itanium, it's essential. (The Itanium needs a near-omniscient compiler to perform well, because you have to decide at compile time which instructions should be executed
Most of the little humanoid toy-sized robots are a joke in the sensor department, but this one has the gyros, accelerometers, and force sensing to, maybe, get it right. Importantly, it has three axes of force sensing on the legs. The Aibo and BDI's Little Dog do not, which limits them to semi-static gaits. If you have that force sensing, you can do slip control and potentially run up hills.
I have a long-standing interest (and some results and patents) in the legged running area, and I'm glad to see the hardware catching up. Simulation is nice, but limiting.
The industry is trying to move to a higher price point. And that's just not going to happen.
It's quite possible that the Xbox 360 and PS3, and their games, will sell slowly at their higher price points, and won't go mainstream until the prices come down, which could take years. The PS2 is still outselling the XBox 360. Microsoft caught up with demand, and nobody cared.
Actually, you can probably use this engine just fine for "destructable environments". It's OK for blowing stuff up. Just turn up the damping and don't set "no sleeping", and all the debris will come to rest.
But if you want to do hard stuff where the physics matters, like legged characters with real physics, it's not there yet.
Try tilting the plane, so that the cone should slide slowly once it stops bouncing. Set "No sleeping", so it doesn't come to rest and stop too soon. Set the collision mode on everything to "Convex Hull Polytope", so the cone isn't treated as a box.
This is failing for point-down, flat side down, and cone side down orientations.
You should be able to model a spinning top with the cone. Spin it up, watch it precess and slow down, then fall over and roll around a bit. That's a basic validity test for a single rigid body system.
Tried the new physics engine, by dropping a cube and a cone onto a slanted plane. Things are definitely better than in 2.41, where the objects just hit the plane and stuck. Now they hit, bounce a bit, and slowly fall to align with the plane. They start to slide.
Then the cone goes spinning and flying off into space. Huge conservation of energy violation. Oops.
The Bullet Physics guys don't have sliding friction right yet. But they're making progress.
Yes. I expect that the next generation of virus-removal tools will be bootable Linux CDs. The "rootkit" attacks are becoming so intrusive that fixing them from inside the running system is becoming hopeless. It has to be done from a stable environment that can't be corrupted, like a read-only CD.
What's new here is how short a pulse they're sending. The light pulse is only about 0.1ns long (the article says "an inch"), which is actually quite good for a big pulsed laser. That's why they get so few photons back.
On the other hand, detecting single photons is no big deal; that's what photomultipliers are for.
The G8 summit is refocusing on the latest war, Israel vs Hezbollah, Lebanon, Syria, etc., and the resulting disruption to oil supplies. Nobody at that level has time for the music industry right now.
There are still advantages to staying with Windows 2000. The absence of a backdoor that allows Microsoft to install software is the big one. The stuff coming in via Windows Update is sometimes a win, and sometimes a lose. Do you want to take that risk? Especially since Microsoft doesn't make any contractual promises that they won't break your machine or install a new security hole. And since occasionally, they do.
Fanuc, the Japanese robot manufacturer, actually does have a robotic kitchen for their employee cafeteria. Robots make up meals and do the heavy pot cleaning. It's not totally automatic. Yet.
All that user intervention is silly. What you want is a combination washer/dryer. These were first offered in 1958, and they're still around. No need to move the clothes from the washer to the dryer. The latest models even dispose of the lint down the drain.
This is way ahead of having to communicate with the thing remotely.
Another idea that seems to have disappeared from washing machines is a soap tank. You just
fill one tank with Liquid Tide, another tank with fabric softener, and it does the rest. That was tried in the 1960s.
Some of the more advanced machines, like the Maytag Neptune, sense the dirt content of the drain water and the water content of the dryer exhaust air to decide automatically how much washing and drying is needed. The Neptune can deal with an out-of-balance condition by itself, too.
Another useful facility would be to have the dryer do an extra few turns every few minutes after it is done, to prevent wrinkling.
Actually, at this point you need to build two things. One is a functional prototype that fits in some standard case. The other is a non-functional prototype that shows the desired look and feel of the product.
The functional prototype you put in some standard case. It will be bigger than the final product, but it will work. Get a good catalog of boxes (Mouser and Digi-Key have good selections.) You'll have to drill holes and grind things down, which you do with hand tools and maybe a Dremel tool.
The look and feel prototype you have designed by someone who understands industrial design. It may be a clay model. There are polymer clays that can be fired in an oven to make a hard object. The model is then painted, and perhaps glue-on stickers are applied, followed by a clear coat.
There are other approaches; you can machine the mockup out of a block of Delrin, or build it up in a stereolithography machine. Or if you just want to have pretty pictures, you can design the case in some 3D system and generate renderings. But for handheld devices, a solid object is more useful.
Now you can get user opinons on the thing. You'll make some mods, and may do another version of either prototype. Marketing and funding efforts begin.
Once you have a basic design that seems to work, you're faced with designing the real thing. This is a packaging job, and you have to think about things like design for assembly, waterproofing, shock and vibration resistance, interconnects, and similar subjects. If you can get the whole thing on one PC board, do so. If you can't, you get into interconnects, always a big hassle. Try for one PC board with surface mount components and a clamshell case that holds it in place; that's straightforward to fabricate in quantity. If your idea is any good, by this point you have some funding. So you get this done by somebody who knows how.
This thing is for real. The predecessor system, the Tactical High Energy Laser, has been shooting down stuff in tests for several years now. It's a joint effort with Israel, which has an ongoing problem with incoming short-range rockets.
Slashdot Mirror
3D Studio was originally written at Autodesk. The Discreet acquisition came later.
R/C car drifting is already here.
The next thing is a stability control system to support drifting, with a rate gyro, to make it easier.
In stores now!
It turns out that the big problem is a bug - large objects don't work right, due to a roundoff problem. If you limit all objects, including the ground, to 50 meters in the longest dimension, they work better.
The total compensation (including fringe benefits) for each of the top five employees of a publicly held company has to be reported to the SEC.
The shareholders should set that amount. You put a number on the proxy, and the share-weighted median of those values is the limit on total compensation for the top five. Management should be allowed to suggest an amount on the proxy, but that shouldn't be the default for unreturned votes.
Now that would make management more responsive.
For mutual funds and retirement plans, the right to set that value has to pass through to the beneficial owners. For a mutual fund, you'd specify a number on the fund's proxy, and the fund's managers would be allowed to specify the compensation limit for each company, but those choices would have to add up in some weighted way to the median of the value set by the real owners, the fundholders.
Fear the Junior Woodchucks.
Wouldn't it be easier to just look at the English version of the page?
No. The English version and the Japanese version are quite different. The good stuff is only on the Japanese pages.
Gee, I had my Slashdot article on the SGI bankruptcy rejected back on May 8th when it actually happened. Two months later, the bankruptcy gets a mention on Slashdot.
SGI's main remaining business is real estate. They own many buildings in Mountain View, most of which they lease to Google. Due to some bad decisions (like signing up for a 55-year land lease in 1995) SGI loses money on that deal. Then they tried a sale/leaseback deal with Goldman Sachs and dug themselves a bigger hole by locking in their rent at the top of the dot-com boom. A friend at Google says that SGI is a "great landlord", though.
SGI doesn't really have much left in the way of manufacturing facilities. The only thing left is Chippewa Falls, the old Cray facility. They had 1,858 employees left at the start of the bankruptcy. SGI had way too much legacy administrative overhead. They had 18 different corporate entities, from Cray to MIPS to Parallel to Alias/Wavefront, and 43 more marketing subsidiaries in various countries. Most of those organizations will disappear in the bankruptcy.
From the filing: In the last several years, SGI has faced a number of challenges, which, taken together, have had a negative impact on SGI's overall financial performance. In the late 1990's, SGI made a series of investments in strategies and technologies that yielded less than the expected results.
Er, right.
Realistically, what happened is that SGI was totally unable to cope with their high-margin business becoming a low-margin business. Few companies succeed at that transition, IBM being a notable exception. And even IBM finally bailed out of PCs.
The article is a bit simplistic.
With medium-level languages like C, some of the language constructs are lower-level than the machine hardware. Thus, a decent compiler has to figure out what the user's code is doing and generate the appropriate instructions. The classic example is
char tab1[100], tab2[100];
int i = 100;
char* p1 = &tab1; char* p2 = &tab2;
while (i--) *p2++ = *p1++;
Two decades ago, C programmers who knew that idiom thought they were cool. In the PDP-11 era, with the non-optimizing compilers that came with UNIX, that was actually useful. The "*p2++ = *p1++;" explicitly told the compiler to generate auto-increment instructions, and considerably shortened the loop over a similar loop written with subscripts. By the late 1980s and 1990s, it didn't matter. Both GCC and the Microsoft compilers were smart enough to hoist subscript arithmetic out of loops, and writing that loop with subscripts generated the same code as with pointers. Today, if you write that loop, most compilers for x86 machines will generate a single MOV instruction for the copy. The compiler has to actually figure out what the programmer intended and rewrite the code. This is non-trivial. In some ways, C makes it more difficult, because it's harder for the compiler to figure out the intent of a C program than a FORTRAN or Pascal program. In C, there are more ways that code can do something wierd, and the compiler must make sure that the wierd cases aren't happening before optimizing.
The next big obstacle to optimization is the "dumb linker" assumption. UNIX has a tradition of dumb linkers, dating back to the PDP-11 linker, which was written in assembler with very few comments. The linker sees the entire program, but, with most object formats, can't do much to it other than throw out unreachable code. This, combined with the usual approach to separate compilation, inhibits many useful optimizations. When code calls a function in another compilation unit, the caller has to assume near-unlimited side effects from the call. This blocks many optimizations. In numerical work, it's a serious problem when the compiler can't tell, say, that "cos(x)" has no side effects. In C, it doesn't; in FORTRAN, it does, which is why some heavy numerical work is still done in FORTRAN. The compiler usually doesn't know that "cos" is a pure function; that is, x == y implies cos(x) = cos(y). This is enough of a performance issue that GCC has some cheats to get around it; look up "mathinline.h". But that doesn't help when you call some one-line function in another compilation unit from inside an inner loop.
C++ has "inline" to help with this problem. The real win with "inline" is not eliminating the call overhead; it's the ability for the optimizers to see what's going on. But really, what should be happening is that the compiler should check each compilation unit and output not machine code, but something like a parse tree. The heavy optimization should be done at link time, when more of the program is visible. There have been some experimental systems that did this, but it remains rare. "Just in time" systems like Java have been more popular. (Java's just-in-time approach is amusing. It was put in because the goal was to support applets in browsers. (Remember applets?) Now that Java is mostly a server-side language, the JIT feature isn't really all that valuable, and all of Java's "packaging" machinery takes up more time than a hard compile would.)
The next step up is to feed performance data from execution back into the compilation process. Some of Intel's embedded system compilers do this. It's most useful for machines where out of line control flow has high costs, and the CPU doesn't have good branch prediction hardware. For modern x86 machines, it's not a big win. For the Itanium, it's essential. (The Itanium needs a near-omniscient compiler to perform well, because you have to decide at compile time which instructions should be executed
Company site, with translation to English. Actual technical details. Pricing.
Most of the little humanoid toy-sized robots are a joke in the sensor department, but this one has the gyros, accelerometers, and force sensing to, maybe, get it right. Importantly, it has three axes of force sensing on the legs. The Aibo and BDI's Little Dog do not, which limits them to semi-static gaits. If you have that force sensing, you can do slip control and potentially run up hills.
I have a long-standing interest (and some results and patents) in the legged running area, and I'm glad to see the hardware catching up. Simulation is nice, but limiting.
The industry is trying to move to a higher price point. And that's just not going to happen.
It's quite possible that the Xbox 360 and PS3, and their games, will sell slowly at their higher price points, and won't go mainstream until the prices come down, which could take years. The PS2 is still outselling the XBox 360. Microsoft caught up with demand, and nobody cared.
Wikipedia needs a database of stuff like that. Wikipedia is full of album and artist articles, but they're not organized in a useful way.
Actually, you can probably use this engine just fine for "destructable environments". It's OK for blowing stuff up. Just turn up the damping and don't set "no sleeping", and all the debris will come to rest.
But if you want to do hard stuff where the physics matters, like legged characters with real physics, it's not there yet.
Try tilting the plane, so that the cone should slide slowly once it stops bouncing. Set "No sleeping", so it doesn't come to rest and stop too soon. Set the collision mode on everything to "Convex Hull Polytope", so the cone isn't treated as a box.
This is failing for point-down, flat side down, and cone side down orientations.
You should be able to model a spinning top with the cone. Spin it up, watch it precess and slow down, then fall over and roll around a bit. That's a basic validity test for a single rigid body system.
Tried the new physics engine, by dropping a cube and a cone onto a slanted plane. Things are definitely better than in 2.41, where the objects just hit the plane and stuck. Now they hit, bounce a bit, and slowly fall to align with the plane. They start to slide.
Then the cone goes spinning and flying off into space. Huge conservation of energy violation. Oops.
The Bullet Physics guys don't have sliding friction right yet. But they're making progress.
Yes. I expect that the next generation of virus-removal tools will be bootable Linux CDs. The "rootkit" attacks are becoming so intrusive that fixing them from inside the running system is becoming hopeless. It has to be done from a stable environment that can't be corrupted, like a read-only CD.
What's new here is how short a pulse they're sending. The light pulse is only about 0.1ns long (the article says "an inch"), which is actually quite good for a big pulsed laser. That's why they get so few photons back.
On the other hand, detecting single photons is no big deal; that's what photomultipliers are for.
He comes across like a General Motors exec from the glory days.
The G8 summit is refocusing on the latest war, Israel vs Hezbollah, Lebanon, Syria, etc., and the resulting disruption to oil supplies. Nobody at that level has time for the music industry right now.
There are still advantages to staying with Windows 2000. The absence of a backdoor that allows Microsoft to install software is the big one. The stuff coming in via Windows Update is sometimes a win, and sometimes a lose. Do you want to take that risk? Especially since Microsoft doesn't make any contractual promises that they won't break your machine or install a new security hole. And since occasionally, they do.
Fanuc, the Japanese robot manufacturer, actually does have a robotic kitchen for their employee cafeteria. Robots make up meals and do the heavy pot cleaning. It's not totally automatic. Yet.
All that user intervention is silly. What you want is a combination washer/dryer. These were first offered in 1958, and they're still around. No need to move the clothes from the washer to the dryer. The latest models even dispose of the lint down the drain.
This is way ahead of having to communicate with the thing remotely.
Another idea that seems to have disappeared from washing machines is a soap tank. You just fill one tank with Liquid Tide, another tank with fabric softener, and it does the rest. That was tried in the 1960s.
Some of the more advanced machines, like the Maytag Neptune, sense the dirt content of the drain water and the water content of the dryer exhaust air to decide automatically how much washing and drying is needed. The Neptune can deal with an out-of-balance condition by itself, too.
Another useful facility would be to have the dryer do an extra few turns every few minutes after it is done, to prevent wrinkling.
So just change the image to a big ad. What's the problem?
Actually, at this point you need to build two things. One is a functional prototype that fits in some standard case. The other is a non-functional prototype that shows the desired look and feel of the product.
The functional prototype you put in some standard case. It will be bigger than the final product, but it will work. Get a good catalog of boxes (Mouser and Digi-Key have good selections.) You'll have to drill holes and grind things down, which you do with hand tools and maybe a Dremel tool.
The look and feel prototype you have designed by someone who understands industrial design. It may be a clay model. There are polymer clays that can be fired in an oven to make a hard object. The model is then painted, and perhaps glue-on stickers are applied, followed by a clear coat. There are other approaches; you can machine the mockup out of a block of Delrin, or build it up in a stereolithography machine. Or if you just want to have pretty pictures, you can design the case in some 3D system and generate renderings. But for handheld devices, a solid object is more useful.
Now you can get user opinons on the thing. You'll make some mods, and may do another version of either prototype. Marketing and funding efforts begin.
Once you have a basic design that seems to work, you're faced with designing the real thing. This is a packaging job, and you have to think about things like design for assembly, waterproofing, shock and vibration resistance, interconnects, and similar subjects. If you can get the whole thing on one PC board, do so. If you can't, you get into interconnects, always a big hassle. Try for one PC board with surface mount components and a clamshell case that holds it in place; that's straightforward to fabricate in quantity. If your idea is any good, by this point you have some funding. So you get this done by somebody who knows how.
Incidentally, having custom membrane keyboards or rubber keyboards like a cell phone made isn't that big a deal, and you can get much of your job done by a supplier in that business.
Here's a press release, with a picture.
This thing is for real. The predecessor system, the Tactical High Energy Laser, has been shooting down stuff in tests for several years now. It's a joint effort with Israel, which has an ongoing problem with incoming short-range rockets.
Here's a 7-minute video, on YouTube.
It's not yet a battlefield weapon - too bulky. But for fixed point defense, it can work.