Bang on. Learning to write code that tests others' modules will teach you a ton about writing code that is testable and what to avoid, and it will teach you about inadequacy of certain styles of in-the-code documentation as well, but you will need to be able to absorb what you're testing as well... sometimes just being a tester isn't good enough to retain everything you've been exposed to. It's much harder to create from scratch than it is to review someone else's work or to add a small tweak.
For me, that's the "real" Motorola. The folks that architected the 6809, the 68000, the 68k peripheral set, and from there designed embedded CPUs that really were single-chip systems. They had far-reaching vision when they designed the 68k... then they dropped the ball with the 88k RISC architecture but knocked another one out of the park with the PowerPC embedded MCUs and CPU cores.
The company I worked with at the time was a competitor of Motorola in the cellular handset market, and so we reviled them for their chutzpah in patenting RF power control and modulation schemes, but their micros and their automotive power semiconductors were awesome back in the day.
On what vehicle are you basing those weights? Rack and pinion systems are lightweight compared to the recirculating-ball or worm-and-sector steering arrangements because they replace the drag link that goes laterally across the car, which means there is less redundant mass in the steering arrangement.
Any manual steering arrangement can be made lighter than a power assisted system and more efficient (with respect to fuel mileage) than a power-assisted system simply because the steering then doesn't impose a parasitic power draw on the engine.
Removing parasitic loads and saving weight improve fuel efficiency. Replacing a manually (driver) powered system with an engine powered system that requires extra pumps or electric actuators does not do that.
Simple: You assume that every bit of power going in is wasted. Therefore, there is no such thing as absolute "conversion efficiency", but using 10 times less power does make you 10 times as efficient, since you get the same bits coming out (assuming the same program and input) for 1/10 the watts going in.
You can design a switching power supply to be 90% or more efficient but only over a relatively narrow current range. So the problem becomes one of management: when everything goes to 'idle' state, the efficiency of your one-box-does-all converter might drop to 1% and you still consume as much power (or more) than having the single dedicated supply for each device.
A second issue is that while PC's have fairly standardized load requirements and voltage bus definitions, that does not hold for AV gear. Most decent audio amps require supplies of 40 to 60 VDC (and a complementary -40 to -60 supply) because at the speakers, power = V^2 / Z. This means that a 100 watt peak amplifier will produce +/- 28V waveform at the (8 ohm) speaker, and require a correspondingly higher supply. Televisions (especially the old-school tube type) had requirements for all kinds of high voltage to drive the deflector coils; this may no longer be true but I'd be surprised if everything was developed to run off a nice tidy 12 volts even in current state of the art LCD or plasma TVs.
The way the studios reduce the top line is to sign away the rights for the movie (its redistribution on DVD, toy tie-ins, etc) to one of its subsidiaries or other organizations under its corporate umbrella, as soon as possible (i.e. as soon as the first run in theaters is over). Therefore, even though the total take from LOTR might have been on the order of $6B, the corporate entity that is the studio might not have seen more than half that, and therefore the amount they are obliged to pay out as a percentage of the studio's gross receipts is limited.
I had to do a Taylor series approximation for sin(x) and cos(x) for a DSP application (about 18 years ago... back when the TMS320C25 was pretty much king of the fixed-point hill). The output needed to be good to about 10 bits and we had a high update rate (40+ kHz). We used a 64-point precomputed lookup table, and that reduced the correction factor to 1/64 * pi. Turns out that when you're doing that, and consider that in binary, pi can be expressed as 11.001001, there is no benefit to carrying anything past the first two bits. So I was able to legitimately use pi=3. Even had we needed 16 bit output, it would probably have been justifiable on computational-complexity grounds to use pi=3.125.
It's only an example of good engineering IF the fault is actually existent in the sensor or system. False-positive fault detection is a nuisance and a danger to the driver. If you're driving along in heavy traffic and suddenly a light comes on in the dash, it's going to distract you, right? At least you need to suddenly make a decision on whether to pull over and see if this is a serious problem. Then, if it is a false indication, then it will eventually lead to the driver ignoring legitimate warnings, potentially causing engine damage.
I have an OBD-II reader and I've used it to diagnose problems with my vehicles... the quality of the information delivered is only as good as the quality of the software that's running on the ECU.
The next best thing is having somebody who's familiar with it draw you a diagram of the overall structure.
I find the best thing is to do the drawing myself. It might take a couple of attempts, but in the process you have to dig into the details and discover the structure. The extra interaction with the code gives a more indepth understanding. If I can draw it, then I can create it, fix it, and explain it to someone else. If I can't draw a particular thing to a desired level of detail (whether it's a piece of hardware, mechanical construction, or software) then I don't really understand it.
yeah, but for that 50% you have guaranteed sunlight. Since the solar flux will be similar to Earth's it should be around 1 kW per square meter, right? It should be fairly straightforward to design a heat containment system that can capture sufficient energy during the daytime, to operate during the dark period and keep temperatures in a reasonable range.
The majority of wasted energy in an internal combustion engine is in the exhaust gas and in the coolant, which is continuously pumped to a radiator. In a conventional gasoline engine about 1/3 of the energy content of the fuel goes out the exhaust pipe, 1/3 gets radiated by the radiator, and only 1/3 actually ends up doing work on the input shaft of the transmission...
This is why turbochargers are often used on high performance engines - it extracts extra energy from the exhaust flow and thereby raises the thermodynamic efficiency of the whole package. Typical exhaust gas temperatures (at the exhaust manifold) are on the order of 1500 degrees F, which is hot enough to do lots of work.
Unfortunate that at least some of that coordinated effort is slated to be decommissioned in the next little while... with both the Hubble and Arecibo (the latter not specifically named, but they did use the VLA radiotelescope) being punted, how much of this capability will we lose?
When software or firmware is a major component of your commercial output, then it is important enough that it should get as much up-front design, in-process review and documentation as your hardware.
Doing good software design up-front saves a huge amount of time in writing and debugging. If you're doing an OO project of any significant complexity and you get your class definitions messed up, then the code implementation is going to suck, both in performance and in maintainability.
It doesn't only apply to big projects. My code is aimed at 1k or 2k FLASH targets... if you don't design it right up front, then it's not going to fit. When you're coding for something that's going to get masked into ROM, you want to be able to show that every line of code has been tested and that there are no degenerate situations. Add to that a realtime environment where you don't know when certain interrupts are going to happen in relation to each other, and proper design becomes the difference between something that works all the time, and something that is dependent on all kinds of seemingly unrelated occurrences.
Let's see... the operating budget is $10.5 million. Assume you should actually kick in, say, 12 million per year to be able to amortize eventual maintenance and upgrades. The disassembly cost is estimated at $100 million, minimum. It should be a no-brainer for someone with $$$ to be able to step in, get a 99 year lease on the property from the government for a nominal fee (guaranteed access to data and certain to-be-negotiated observation timeslots?), and the new owner starts a science trust fund with a float of, say, 300 million. That money is invested, and the operating budget for Arecibo comes out of the investment return, leaving the principal untouched (assuming a conservative after-overhead return of about 4%).
There are any number of neo-gazillionaires that should be able to support that... how about it?
As related here high-voltage DC transmission is more efficient than high voltage AC transmission for a number of reasons, and it has other benefits as well in allowing potentially unsynchronized AC systems to transfer power. The main problem is efficient voltage conversion, which requires more infrastructure than an AC system with equivalent power transfer capability.
How long until a significant proportion of local users have a hybrid AC/DC system to manage power distribution from power generated on site? Tesla certainly won the medium power, wide area power distribution battle, but there are a lot of developments taking place that will increase the visibility of DC power generation.
Taking control (or, at least trying to) has been a pretty successful approach for me. I've been out running several times where a dog would run at me, barking, presumably with the intent to at least scare me off. I'd slow down, but keep walking towards them (on the road, not on their turf) while yelling and pointing at them. When they start to back off, I'd start running towards them while still yelling at them, which typically causes the dog to turn tail and run. At least until it's time for me to get on with my run... gotta keep checking to see they don't come back and try to chase me down.
My main intent is to teach the dog to not mess with runners, or at least to not mess with me. If they are aggressive and are also stupid enough to let me get within kicking distance, then they're going to get a boot into any part of them that I can reach.
TFA mentions some details of the source text that indicates they started out in Hebrew. A likely problem with that (as I understand it) is that since written Hebrew doesn't use vowels, a lot of the interpretation of text is context sensitive, and Babelfish screwed it up.
Having used Babelfish for fun a few times, I've seen it twist the meaning of things fabulously especially when the input and output languages have different grammatical construction. The way to use Babelfish with a little more consideration is to run your text through, then run the output back into your original language and see what you get back. If it's not close to the same meaning... figure out a different way to say it.
For most obscure result, do intermediate translations among languages that have completely different roots, for example: English->Japanese->Spanish->Urdu->Dutch. Bonus for including Hungarian or Finnish, since those languages don't share common roots with any other.
There are many toys that we've bought for our kids where the 'suggested age' is higher than the age they were at that time. However, when doing that, we're still making the assumption that the risks associated with those toys are ones that we're familiar with. As an example of the beads, anyone playing with them would be exposed to GHB if they swallowed them. We know enough to stop our kids from doing that, and to tell them not to. However, kids' hands are often in their mouths, and they're susceptible to ingestion of the bead coating just by touching the beads with wet fingers and then putting their hands in their mouths. Would you recognize that as a dangerous situation if you hadn't ever heard of this story? Last year our oldest lost four baby teeth, and he was in there wiggling teeth for about nine months straight. Couple that with a situation where the surface of the toys he's playing with is toxic, and he'd be a prime candidate for long term physiological damage.
Whatever your personal involvement with your kids' playing, you're always making a basic assumption that you understand the risks involved. Consequently, when the manufacturer screws up and creates a toy that has an unexpected failure mode, you and your child are at risk. Nothing you can do about that unless you make your own toys using parts and finish materials where you know EXACTLY what is in it, or (for litigious bastards) if you think that extracting a couple of million from $(TOYMAKER) is a reasonable exchange for you and your child's future. Accordingly, we all take risks. We just hope we know what they are.
You don't have kids, do you? Kids put stuff in their mouths. Even when you tell them not to. And the second time... and the next. Because they're kids. And if you have multiple kids you sometimes end up with toys in the house that are intended for older kids, and the little ones still end up playing with them because kids get into stuff.
That's not to say that parents aren't responsible for what's in the house and within reach of kids, but there's a basic expectation that children's toys such as beads and cars aren't going to be poisonous or otherwise chemically hazardous. Chemistry sets are a different matter... but even there you wouldn't expect radioactive compounds or highly toxic materials in a children's set.
With very few exceptions, racing has always had rules, both for vehicle preparation and driver conduct. Those that say "Formula 1 ought to be completely unrestricted" don't understand what "Formula" means in the context of motorsport.
The rules for Peter Diamandis' vehicle X prize are interesting. I don't have a link, but the goal (for 4 occupant, 4 wheeled vehicles) is: 100 MPG, 100 MPH top speed, 10 seconds 0-60, all normally required vehicle safety and weather gear (heater, wipers, crash protection, AC very desirable), and the testing will be done on real roads in real traffic.
I'm seeing how far I can push my 2000 Echo for mileage. My current goal is 800 km (500 miles) on a tank ( 40 liters, give or take). I've made 750 km, but then I changed out the rock-hard Michelin tires for Nokians that will actually allow me to survive the winter...
That is (or used to be) part of the Indycar formula, and was also previously used in F1, in the turbo era. You got X amount of fuel based on the race distance to be covered, and it was up to you to manage how it was spent. For Indycar it was based on 4 MPG mileage (methanol has about 1/2 the energy density, by volume, of gasoline) I believe. Some races were mileage-fests and some (typically, if there were a few yellows) allowed the drivers to exercise the boost control vigorously.
In F1 the mileage thing was instituted as a power limiting measure but all it really ended up doing was to increase the cost of competition significantly. The teams with big research budgets figured out how to make their engines last on lean mixtures, and they were able to outrun and outlast everyone else.
That would be much better than anything resulting in "HOLY SHIT!"
Props to John and the rest of the team at Armadillo. However hard it is to do these flights at any time, doing a command performance on a particular day has got to be an order of magnitude more difficult.
Slashdot Mirror
Bang on. Learning to write code that tests others' modules will teach you a ton about writing code that is testable and what to avoid, and it will teach you about inadequacy of certain styles of in-the-code documentation as well, but you will need to be able to absorb what you're testing as well... sometimes just being a tester isn't good enough to retain everything you've been exposed to. It's much harder to create from scratch than it is to review someone else's work or to add a small tweak.
The company I worked with at the time was a competitor of Motorola in the cellular handset market, and so we reviled them for their chutzpah in patenting RF power control and modulation schemes, but their micros and their automotive power semiconductors were awesome back in the day.
Any manual steering arrangement can be made lighter than a power assisted system and more efficient (with respect to fuel mileage) than a power-assisted system simply because the steering then doesn't impose a parasitic power draw on the engine.
Removing parasitic loads and saving weight improve fuel efficiency. Replacing a manually (driver) powered system with an engine powered system that requires extra pumps or electric actuators does not do that.
Simple: You assume that every bit of power going in is wasted. Therefore, there is no such thing as absolute "conversion efficiency", but using 10 times less power does make you 10 times as efficient, since you get the same bits coming out (assuming the same program and input) for 1/10 the watts going in.
A second issue is that while PC's have fairly standardized load requirements and voltage bus definitions, that does not hold for AV gear. Most decent audio amps require supplies of 40 to 60 VDC (and a complementary -40 to -60 supply) because at the speakers, power = V^2 / Z. This means that a 100 watt peak amplifier will produce +/- 28V waveform at the (8 ohm) speaker, and require a correspondingly higher supply. Televisions (especially the old-school tube type) had requirements for all kinds of high voltage to drive the deflector coils; this may no longer be true but I'd be surprised if everything was developed to run off a nice tidy 12 volts even in current state of the art LCD or plasma TVs.
The way the studios reduce the top line is to sign away the rights for the movie (its redistribution on DVD, toy tie-ins, etc) to one of its subsidiaries or other organizations under its corporate umbrella, as soon as possible (i.e. as soon as the first run in theaters is over). Therefore, even though the total take from LOTR might have been on the order of $6B, the corporate entity that is the studio might not have seen more than half that, and therefore the amount they are obliged to pay out as a percentage of the studio's gross receipts is limited.
I had to do a Taylor series approximation for sin(x) and cos(x) for a DSP application (about 18 years ago... back when the TMS320C25 was pretty much king of the fixed-point hill). The output needed to be good to about 10 bits and we had a high update rate (40+ kHz). We used a 64-point precomputed lookup table, and that reduced the correction factor to 1/64 * pi. Turns out that when you're doing that, and consider that in binary, pi can be expressed as 11.001001, there is no benefit to carrying anything past the first two bits. So I was able to legitimately use pi=3. Even had we needed 16 bit output, it would probably have been justifiable on computational-complexity grounds to use pi=3.125.
I have an OBD-II reader and I've used it to diagnose problems with my vehicles... the quality of the information delivered is only as good as the quality of the software that's running on the ECU.
Bad link on that one... try this, and try not to cringe.
No way. Tori's bicycle face plant takes both of those, hands (and face) down.
I find the best thing is to do the drawing myself. It might take a couple of attempts, but in the process you have to dig into the details and discover the structure. The extra interaction with the code gives a more indepth understanding. If I can draw it, then I can create it, fix it, and explain it to someone else. If I can't draw a particular thing to a desired level of detail (whether it's a piece of hardware, mechanical construction, or software) then I don't really understand it.
yeah, but for that 50% you have guaranteed sunlight. Since the solar flux will be similar to Earth's it should be around 1 kW per square meter, right? It should be fairly straightforward to design a heat containment system that can capture sufficient energy during the daytime, to operate during the dark period and keep temperatures in a reasonable range.
This is why turbochargers are often used on high performance engines - it extracts extra energy from the exhaust flow and thereby raises the thermodynamic efficiency of the whole package. Typical exhaust gas temperatures (at the exhaust manifold) are on the order of 1500 degrees F, which is hot enough to do lots of work.
Unfortunate that at least some of that coordinated effort is slated to be decommissioned in the next little while... with both the Hubble and Arecibo (the latter not specifically named, but they did use the VLA radiotelescope) being punted, how much of this capability will we lose?
When software or firmware is a major component of your commercial output, then it is important enough that it should get as much up-front design, in-process review and documentation as your hardware.
Doing good software design up-front saves a huge amount of time in writing and debugging. If you're doing an OO project of any significant complexity and you get your class definitions messed up, then the code implementation is going to suck, both in performance and in maintainability.
It doesn't only apply to big projects. My code is aimed at 1k or 2k FLASH targets... if you don't design it right up front, then it's not going to fit. When you're coding for something that's going to get masked into ROM, you want to be able to show that every line of code has been tested and that there are no degenerate situations. Add to that a realtime environment where you don't know when certain interrupts are going to happen in relation to each other, and proper design becomes the difference between something that works all the time, and something that is dependent on all kinds of seemingly unrelated occurrences.
There are any number of neo-gazillionaires that should be able to support that... how about it?
As related here high-voltage DC transmission is more efficient than high voltage AC transmission for a number of reasons, and it has other benefits as well in allowing potentially unsynchronized AC systems to transfer power. The main problem is efficient voltage conversion, which requires more infrastructure than an AC system with equivalent power transfer capability.
How long until a significant proportion of local users have a hybrid AC/DC system to manage power distribution from power generated on site? Tesla certainly won the medium power, wide area power distribution battle, but there are a lot of developments taking place that will increase the visibility of DC power generation.
My main intent is to teach the dog to not mess with runners, or at least to not mess with me. If they are aggressive and are also stupid enough to let me get within kicking distance, then they're going to get a boot into any part of them that I can reach.
Having used Babelfish for fun a few times, I've seen it twist the meaning of things fabulously especially when the input and output languages have different grammatical construction. The way to use Babelfish with a little more consideration is to run your text through, then run the output back into your original language and see what you get back. If it's not close to the same meaning... figure out a different way to say it.
For most obscure result, do intermediate translations among languages that have completely different roots, for example: English->Japanese->Spanish->Urdu->Dutch. Bonus for including Hungarian or Finnish, since those languages don't share common roots with any other.
Whatever your personal involvement with your kids' playing, you're always making a basic assumption that you understand the risks involved. Consequently, when the manufacturer screws up and creates a toy that has an unexpected failure mode, you and your child are at risk. Nothing you can do about that unless you make your own toys using parts and finish materials where you know EXACTLY what is in it, or (for litigious bastards) if you think that extracting a couple of million from $(TOYMAKER) is a reasonable exchange for you and your child's future. Accordingly, we all take risks. We just hope we know what they are.
That's not to say that parents aren't responsible for what's in the house and within reach of kids, but there's a basic expectation that children's toys such as beads and cars aren't going to be poisonous or otherwise chemically hazardous. Chemistry sets are a different matter... but even there you wouldn't expect radioactive compounds or highly toxic materials in a children's set.
The rules for Peter Diamandis' vehicle X prize are interesting. I don't have a link, but the goal (for 4 occupant, 4 wheeled vehicles) is: 100 MPG, 100 MPH top speed, 10 seconds 0-60, all normally required vehicle safety and weather gear (heater, wipers, crash protection, AC very desirable), and the testing will be done on real roads in real traffic.
I'm seeing how far I can push my 2000 Echo for mileage. My current goal is 800 km (500 miles) on a tank ( 40 liters, give or take). I've made 750 km, but then I changed out the rock-hard Michelin tires for Nokians that will actually allow me to survive the winter...
In F1 the mileage thing was instituted as a power limiting measure but all it really ended up doing was to increase the cost of competition significantly. The teams with big research budgets figured out how to make their engines last on lean mixtures, and they were able to outrun and outlast everyone else.
That would be much better than anything resulting in "HOLY SHIT!" Props to John and the rest of the team at Armadillo. However hard it is to do these flights at any time, doing a command performance on a particular day has got to be an order of magnitude more difficult.