I don't think that downshifting is somehow safer in bad weather. I think you're mistaken and are repeating a myth that has no backing in physics of traction. Just think about it: when you downshift, on 2WD cars you are applying braking torque to two of the wheels. There is no benefit to braking with just two wheels that I could think of, compared to all four wheels like you get when you use hydraulic brakes. On RWD cars, engine braking is even worse: it uses the two wheels with least braking capacity -- braking shifts the car weight onto the front wheels, and rear wheels will lose traction first under given braking torque, compared to front wheels! Moreover, engine braking is not subject to ABS: when you lose traction when engine braking, you have to manually recover by applying the clutch. On cars with ABS, traction loss due to applying brakes is recovered from automatically.
The only proper use of engine braking is on prolonged downhill stretches, where you'd otherwise experience brake fade. Every automatic I've seen so far has a downshift mode just for such occasions. There's no other legitimate use for it, especially not in bad weather. You're just spewing nonsense.
Using a digital computer in and of itself isn't a "serious safety issue". The safety problems, if any, result from poor system design taken as a whole. Digital computers, when applied correctly, are just as reliable as plain-old electromechanical logic. I'm perfectly happy routing emergency stop signals using safety-rated digital computing modules, on an office ethernet network no less. The rating of the safety stop is SIL-3. This is on a machine where the e-stop by itself won't cause issues (shutdown is always safe) -- of course there are machines where an abrupt shutdown is not what you want and then you need a more robust connection for the e-stop signals.
My nitpicks:
1. The user interface needs to be intuitive in light of people not reading the manual: pressing the start/stop button for many seconds to turn the car off -- WTF were they thinking? And what's wrong with a rotary switch, like, you know, the good ole ignition switch?
2. The control system needs to detect conflicting inputs: when brake is depressed, cut the throttle no matter what.
3. The accelerator pedal needs two kinds of sensors -- not only to detect sensor issues, but also to detect mechanical malfunction. A gas-by-wire pedal is essentially a poor-man's force sensor: a spring converts actuation force to displacement, and the displacement is then measured. I say put a darn strain gage on the pedal assembly so that you measure the bending moment as well, and then not only you have diverse inputs, but you can actually detect seizure of the pivot bushing -- the hysteresis loop on the force/displacement graph widens as the bushing friction increases. You'd think it's a no-brainer, but maybe not -- maybe I should patent that or something;)
And people think I'm crazy when I drive automatic cars with two feet (left on the brake, right on the accelerator). Seems to take a whole failure mode out of the equation now, doesn't it, huh? (puts on a smug expression) I can't imagine what it'd take for me to press the accelerator instead of the brake. If my feet would shift such that the right foot would actuate both pedals, the left food would immediately sense the brake pedal going down. Never mind that changing lanes on a crowded freeway (think Chicago) is way easier when you don't waste time by moving one foot between pedals.
A safety rated emergency stop system can be in fact all-digital. Such systems are in daily use in industrial machinery. Heck, the e-stop signals are even routed on "black networks" such as general purpose ethernet gear! The intelligence is in the end nodes -- the safety rated I/O points and safety PLCs. They can cope with the network mangling the data or losing connection. They behave then as if the e-stop was actuated.
Of course the safety controller has usually to be one a separate CPU, since it's hard to demonstrate proper partitioning on general purpose microcontrollers.
When Feynman was setting up discretized integrations using IBM machines for the Manhattan project, he made a human calculator model for what the IBM kit would do. The girls calculated as fast as the IBM punched-card based system of tabulators, collators, multipliers, adders, etc. In his words:
The only difference was that the IBM machines didn't get tired and could work three shifts. But the girls got tired after a while.
Youe learned to speak the language of artists, and the language of software developers. On the surface, it's all English, but your background let you understand the prevalent patterns of thought and specific terms used in both areas. That's hardly what typical GEC college humanities would teach you. What you did ended up making you an ethnologist of sorts. It is a very specific skill: it won't make you better at communicating with doctors, or politicians.
As others have replied: I'm not claiming that art is useless. It's part of what makes us humans, human. It makes life worth living, in a way. I'm claiming that GEC-style peddling of humanities as an end-all, be-all expand teh horizons-or-else, is silly. You did what you liked and you ended up as a programmer: great. Now let me make you take a sociology course and see how much fun that would be.
The problem is that when all that you do is taking others' ideas, you won't ever innovate. Maybe that explains why the finance business world has been, um, suffering recently. They were cheating as long as they could. I'm perfectly fine with academia being "out of touch" with that aspect of "modern working society", thankyouverymuch.
I had a numerical methods class like that, but it was all homework, no exams. Took 20+ hours per week just to do the homework. The material taught was such that it would make little sense to have exams: you had to get working code, and then "prove" (to teacher's satisfaction) that the results you were getting were correct. That was the "proof in the pudding". It was a very practical class. If you wouldn't do the work, you wouldn't pass. Doing the work was how you learned in that class. I remember it fondly, even though I get sleepy each time I mention it.
If you're a programmer, it really helps to expand your horizons a bit to have some backing in a "hard" science, like say physics, maths, chemistry, biology, or computer science. Going the other way, programming background definitely makes your life much easier when time comes to do lab reports and data processing in any science class. But the experience you gain applying programming to hard science problem solving is I think very valuable: it teaches you a certain discipline and problem breakdown skills. Those are very important when you'll face large IT problems/issues: you will have an instinct to break them down into manageable pieces.
<rant>I don't think that humanities are necessary, useful, or horizon-expanding, for that matter: hard sciences are a study of all Nature, with results that often are very widely applicable, whereas humanities are a specialized study of mostly artistic output of homo sapiens. Knowing literature won't help you in understanding what makes our world work, but knowing biochemistry may well help you understand what made your favorite author "tick";)</rant>
Isn't homeschooling somewhat at odds with what is meant by latch-key, at least in the U.S.? Latch-key here refers to pre- and after-school childcare programs for parents who are at work and have to drop kids off at school before the start of regular school day, or who have to pick kids up late.
I'm no fan of homeschooling, but admittedly we have to fix plenty of misconceptions and plain lies taught to our 1st grader daughter. If you didn't know, human body is a solid, as taught by a major city school district in Ohio, and then by a highfalutin' taxed-through-the-roof smaller district.
Upon realizing that she learned this "fact", we just couldn't but had to demonstrate to her how to make a water-oil emulsion, followed by making a flour-in-water suspension, and sand-in-water one, too, followed by running a bunch of veggies through a blender and letting the mixture separate. Cell walls here, cell innards there. She even saw some shattered cell walls alright under a microscope. Solid body, my ass. Maybe frozen.
LOL, Wakefield's paper was pretty much a lot of hot air without any solid conclusions, a paper that would have never gathered lots of attention if it weren't for the brainless division of the "think of teh children" club. Wakefield never said "teh vaccines cause autism, teh vaccines bad". It was blown out of proportion by media idiots.
Forgot to say the obvious: yes, you could say a little bit over 1% of the propellant (combined fuel+oxidizer). You'd still have to assume that whatever mechanical strong points needed to apply the pushing force come for free in terms of weight -- that's a rather unlikely scenario. Never mind loss of fault tolerance.
Easy to calculate. The nice thing is that you don't need to worry about any properties of the elastic band. We will simply assume that you want to replace the thrust available for the length of the launch tower with a mechanical pusher, for some existing rocket.
Let's say we were to "optimize" Falcon 9 that way. Falcon 9 has qty 9 Merlin-1C engines, each operating at isp=300s and thrust=560kN at sea level. From that we get that each of those engines consumes about 190kg/s of combined propellant (fuel+oxidizer), so that's about 1700kg/s for the whole rocket: it sheds almost two tons every second.
The initial weight of the stack is about 333e3 kg. Under 560kN*9, the stack accelerates at about 15m/s^2 initially. Assuming this acceleration to be constant -- for simplicity, it takes about 2.8s to clear the ~60m long service arm. The weight savings would be at best the amount of propellant spent in that time: about 4.8e3kg, or 1.4% of the total weight.
If you ask me: absolutely, hands down not worth it, since you'd sacrifice quite a lot. You'd forfeit is hold-down engine run-up: Space X rockets launch not unlike jets - they can get full thrust from the engines with the brakes applied; should anything go wrong you cut the engines and are safe. Suddenly launch success is very sensitive to engine startup issues: you get only one go at engine startup, and if that somehow fails due to any glitch you come crashing down a few seconds later.
What he IS trying to do is make sure that the board doesn't look at this document and treat it like an official engineering document -- signed off by a professional engineer.
You mean the board can't read the effing document and see that there's no PE seal anywhere on it? Professional engineering feel, my ass. Because what, it doesn't look like a slashdot post?!
There is a limit to how stupid one can be. You can't retort everything that lands on your desk with "bbbut, I could have been misled, couldn't I now?". There must be intent to mislead, and the professional capacity of the recipient of this report (a city engineer, no less) all would play a role if the case was ever brought into a courtroom.
As far as I'm concerned, Objective-C was not ever hot, unless you mean hot like radioactive. On my personal klude-o-meter it beats things like MetaSQL hands-down. IMHO if you can beat a straitjacketed industry-born mindless f-up like the latter (alien syntax spice FTW), that means something. There should be a hall of fame or something for such things;) I'd have personally liked it better if Apple bet on, say, Symbolics, and used their technology. At least they'd get a powerful, extensible core language.
This would be funny if it wasn't true in a way. Many non-technical users are treating computers as a system: to them, software and hardware are hard to distinguish. If it doesn't work, you get a new one. Plenty of perfectly good (hardware-wise) PCs have been tossed because Windows has ceased to operate (usually due to malware).
Couldn't agree more. Most regulatory frameworks are overhyped. When you actually sit down and read the law and relevant regulations (if such exist), you realize that the hype has been fueling lots of oh-shit-what-do-I-do-now type of CYA spending for consultants and "solution providers". The real issue? Execs can't be bothered to RTFL (refer to the fine law) and such. They will listen to (and take for good money) bullshit made up by various advisors and consultants who only have their own interests in mind.
I've recently looked at Android API documentation, and it seems to be a rather clean and understandable design. I've dabbled a bit with the SDK and running my code on one of those cheap Augen Android-based tablets from Kmart, and going past "hello world" was quite painless. Then, for reasons I can't quite understand, I seem to puke a little bit every time I see Objective C code. It just looks so darn ugly. For whatever reason I just can't stand some of Apple's APIs. Never mind that they plainly don't document some -- you'd think -- pretty basic parts of their API, at least on the desktop. Case in point: just try to find out how to open up a raw socket on a selected network interface and you'll see what I mean. One shouldn't need to google for that. By "selected" network interface I mean you know the name like en0, but the interface has no IP or anything else.
And that comes from a guy who doesn't mind seeing legacy LISP code (like Maxima sources that I used to browse quite a bit), who doesn't mind various more- and less-pure functional languages (OCaml, Haskell) and functional "hacks" like LINQ, and who can wholeheartedly embrace "customizations" like xmos's XC parallellizable variant of C. I can even stand most of IEC 61131-3 languages. I guess beauty is in the eye of the beholder...
I do agree that I was ahead of myself. Now for nitpicks:
Aerogel isn't a daydream. You can buy it. Costs reasonable amounts, even. If you wanted to insulate particularly hot CPU/GPU heatsinks in a laptop from the bottom of the case, a few mm of aerogel would be my choice, at a cost of maybe $10 or so. Maybe not in a $200 netbook, but Apple sure could pull that off if they needed to. Hot heatsinks are much easier to cool.
Superconductors are problematic due to rather theoretical reasons, too: good luck when you lose cooling (see what happened to LHC). Supercapacitors and low ESR don't mix. You get one or the other, and I think the reasons are to do with fundamental properties of the class of materials used in their design.
I don't really think that electric hybrids are very good at what they claim to do. Practical -- sure, but not very good at all. Unfortunately, neither are hydraulic hybrids, even 100% efficient ones, or really any other kind of hybrid, and I think that's where the buck stops.
But at least the theoretical limit is full efficiency. With most hybrid-electric systems, the theoretical limit is under 100% simply due to resistance of various parts of the circuit and chemical behavior of the batteries.
There are some pretty darn good insulators out there. Think aerogel -- heck, that one even has scalable price vs. performance. You chose density that you can afford (lower: more expensive), trading off performance for better price.
Slashdot Mirror
I don't think that downshifting is somehow safer in bad weather. I think you're mistaken and are repeating a myth that has no backing in physics of traction. Just think about it: when you downshift, on 2WD cars you are applying braking torque to two of the wheels. There is no benefit to braking with just two wheels that I could think of, compared to all four wheels like you get when you use hydraulic brakes. On RWD cars, engine braking is even worse: it uses the two wheels with least braking capacity -- braking shifts the car weight onto the front wheels, and rear wheels will lose traction first under given braking torque, compared to front wheels! Moreover, engine braking is not subject to ABS: when you lose traction when engine braking, you have to manually recover by applying the clutch. On cars with ABS, traction loss due to applying brakes is recovered from automatically.
The only proper use of engine braking is on prolonged downhill stretches, where you'd otherwise experience brake fade. Every automatic I've seen so far has a downshift mode just for such occasions. There's no other legitimate use for it, especially not in bad weather. You're just spewing nonsense.
Using a digital computer in and of itself isn't a "serious safety issue". The safety problems, if any, result from poor system design taken as a whole. Digital computers, when applied correctly, are just as reliable as plain-old electromechanical logic. I'm perfectly happy routing emergency stop signals using safety-rated digital computing modules, on an office ethernet network no less. The rating of the safety stop is SIL-3. This is on a machine where the e-stop by itself won't cause issues (shutdown is always safe) -- of course there are machines where an abrupt shutdown is not what you want and then you need a more robust connection for the e-stop signals.
My nitpicks:
1. The user interface needs to be intuitive in light of people not reading the manual: pressing the start/stop button for many seconds to turn the car off -- WTF were they thinking? And what's wrong with a rotary switch, like, you know, the good ole ignition switch?
2. The control system needs to detect conflicting inputs: when brake is depressed, cut the throttle no matter what.
3. The accelerator pedal needs two kinds of sensors -- not only to detect sensor issues, but also to detect mechanical malfunction. A gas-by-wire pedal is essentially a poor-man's force sensor: a spring converts actuation force to displacement, and the displacement is then measured. I say put a darn strain gage on the pedal assembly so that you measure the bending moment as well, and then not only you have diverse inputs, but you can actually detect seizure of the pivot bushing -- the hysteresis loop on the force/displacement graph widens as the bushing friction increases. You'd think it's a no-brainer, but maybe not -- maybe I should patent that or something ;)
And people think I'm crazy when I drive automatic cars with two feet (left on the brake, right on the accelerator). Seems to take a whole failure mode out of the equation now, doesn't it, huh? (puts on a smug expression) I can't imagine what it'd take for me to press the accelerator instead of the brake. If my feet would shift such that the right foot would actuate both pedals, the left food would immediately sense the brake pedal going down. Never mind that changing lanes on a crowded freeway (think Chicago) is way easier when you don't waste time by moving one foot between pedals.
A safety rated emergency stop system can be in fact all-digital. Such systems are in daily use in industrial machinery. Heck, the e-stop signals are even routed on "black networks" such as general purpose ethernet gear! The intelligence is in the end nodes -- the safety rated I/O points and safety PLCs. They can cope with the network mangling the data or losing connection. They behave then as if the e-stop was actuated.
Of course the safety controller has usually to be one a separate CPU, since it's hard to demonstrate proper partitioning on general purpose microcontrollers.
When Feynman was setting up discretized integrations using IBM machines for the Manhattan project, he made a human calculator model for what the IBM kit would do. The girls calculated as fast as the IBM punched-card based system of tabulators, collators, multipliers, adders, etc. In his words:
The only difference was that the IBM machines didn't get tired and could work three shifts. But the girls got tired after a while.
Never mind that he loved being around girls ;)
Youe learned to speak the language of artists, and the language of software developers. On the surface, it's all English, but your background let you understand the prevalent patterns of thought and specific terms used in both areas. That's hardly what typical GEC college humanities would teach you. What you did ended up making you an ethnologist of sorts. It is a very specific skill: it won't make you better at communicating with doctors, or politicians.
As others have replied: I'm not claiming that art is useless. It's part of what makes us humans, human. It makes life worth living, in a way. I'm claiming that GEC-style peddling of humanities as an end-all, be-all expand teh horizons-or-else, is silly. You did what you liked and you ended up as a programmer: great. Now let me make you take a sociology course and see how much fun that would be.
This!! +1 everything
The problem is that when all that you do is taking others' ideas, you won't ever innovate. Maybe that explains why the finance business world has been, um, suffering recently. They were cheating as long as they could. I'm perfectly fine with academia being "out of touch" with that aspect of "modern working society", thankyouverymuch.
I had a numerical methods class like that, but it was all homework, no exams. Took 20+ hours per week just to do the homework. The material taught was such that it would make little sense to have exams: you had to get working code, and then "prove" (to teacher's satisfaction) that the results you were getting were correct. That was the "proof in the pudding". It was a very practical class. If you wouldn't do the work, you wouldn't pass. Doing the work was how you learned in that class. I remember it fondly, even though I get sleepy each time I mention it.
Let us know what projects are you working on, so that we can avoid the infrastructure or skip buying the product.
If you're a programmer, it really helps to expand your horizons a bit to have some backing in a "hard" science, like say physics, maths, chemistry, biology, or computer science. Going the other way, programming background definitely makes your life much easier when time comes to do lab reports and data processing in any science class. But the experience you gain applying programming to hard science problem solving is I think very valuable: it teaches you a certain discipline and problem breakdown skills. Those are very important when you'll face large IT problems/issues: you will have an instinct to break them down into manageable pieces.
<rant>I don't think that humanities are necessary, useful, or horizon-expanding, for that matter: hard sciences are a study of all Nature, with results that often are very widely applicable, whereas humanities are a specialized study of mostly artistic output of homo sapiens. Knowing literature won't help you in understanding what makes our world work, but knowing biochemistry may well help you understand what made your favorite author "tick" ;)</rant>
Isn't homeschooling somewhat at odds with what is meant by latch-key, at least in the U.S.? Latch-key here refers to pre- and after-school childcare programs for parents who are at work and have to drop kids off at school before the start of regular school day, or who have to pick kids up late.
I'm no fan of homeschooling, but admittedly we have to fix plenty of misconceptions and plain lies taught to our 1st grader daughter. If you didn't know, human body is a solid, as taught by a major city school district in Ohio, and then by a highfalutin' taxed-through-the-roof smaller district.
Upon realizing that she learned this "fact", we just couldn't but had to demonstrate to her how to make a water-oil emulsion, followed by making a flour-in-water suspension, and sand-in-water one, too, followed by running a bunch of veggies through a blender and letting the mixture separate. Cell walls here, cell innards there. She even saw some shattered cell walls alright under a microscope. Solid body, my ass. Maybe frozen.
LOL, Wakefield's paper was pretty much a lot of hot air without any solid conclusions, a paper that would have never gathered lots of attention if it weren't for the brainless division of the "think of teh children" club. Wakefield never said "teh vaccines cause autism, teh vaccines bad". It was blown out of proportion by media idiots.
Forgot to say the obvious: yes, you could say a little bit over 1% of the propellant (combined fuel+oxidizer). You'd still have to assume that whatever mechanical strong points needed to apply the pushing force come for free in terms of weight -- that's a rather unlikely scenario. Never mind loss of fault tolerance.
Easy to calculate. The nice thing is that you don't need to worry about any properties of the elastic band. We will simply assume that you want to replace the thrust available for the length of the launch tower with a mechanical pusher, for some existing rocket.
Let's say we were to "optimize" Falcon 9 that way. Falcon 9 has qty 9 Merlin-1C engines, each operating at isp=300s and thrust=560kN at sea level.
From that we get that each of those engines consumes about 190kg/s of combined propellant (fuel+oxidizer), so that's about 1700kg/s for the whole rocket: it sheds almost two tons every second.
The initial weight of the stack is about 333e3 kg. Under 560kN*9, the stack accelerates at about 15m/s^2 initially. Assuming this acceleration to be constant -- for simplicity, it takes about 2.8s to clear the ~60m long service arm. The weight savings would be at best the amount of propellant spent in that time: about 4.8e3kg, or 1.4% of the total weight.
If you ask me: absolutely, hands down not worth it, since you'd sacrifice quite a lot. You'd forfeit is hold-down engine run-up: Space X rockets launch not unlike jets - they can get full thrust from the engines with the brakes applied; should anything go wrong you cut the engines and are safe. Suddenly launch success is very sensitive to engine startup issues: you get only one go at engine startup, and if that somehow fails due to any glitch you come crashing down a few seconds later.
Waitaminute, a City Engineer is not a P.E.?!
What he IS trying to do is make sure that the board doesn't look at this document and treat it like an official engineering document -- signed off by a professional engineer.
You mean the board can't read the effing document and see that there's no PE seal anywhere on it? Professional engineering feel, my ass. Because what, it doesn't look like a slashdot post?!
There is a limit to how stupid one can be. You can't retort everything that lands on your desk with "bbbut, I could have been misled, couldn't I now?". There must be intent to mislead, and the professional capacity of the recipient of this report (a city engineer, no less) all would play a role if the case was ever brought into a courtroom.
ZModem FTW ;)
As far as I'm concerned, Objective-C was not ever hot, unless you mean hot like radioactive. On my personal klude-o-meter it beats things like MetaSQL hands-down. IMHO if you can beat a straitjacketed industry-born mindless f-up like the latter (alien syntax spice FTW), that means something. There should be a hall of fame or something for such things ;) I'd have personally liked it better if Apple bet on, say, Symbolics, and used their technology. At least they'd get a powerful, extensible core language.
This would be funny if it wasn't true in a way. Many non-technical users are treating computers as a system: to them, software and hardware are hard to distinguish. If it doesn't work, you get a new one. Plenty of perfectly good (hardware-wise) PCs have been tossed because Windows has ceased to operate (usually due to malware).
Couldn't agree more. Most regulatory frameworks are overhyped. When you actually sit down and read the law and relevant regulations (if such exist), you realize that the hype has been fueling lots of oh-shit-what-do-I-do-now type of CYA spending for consultants and "solution providers". The real issue? Execs can't be bothered to RTFL (refer to the fine law) and such. They will listen to (and take for good money) bullshit made up by various advisors and consultants who only have their own interests in mind.
I've recently looked at Android API documentation, and it seems to be a rather clean and understandable design. I've dabbled a bit with the SDK and running my code on one of those cheap Augen Android-based tablets from Kmart, and going past "hello world" was quite painless. Then, for reasons I can't quite understand, I seem to puke a little bit every time I see Objective C code. It just looks so darn ugly. For whatever reason I just can't stand some of Apple's APIs. Never mind that they plainly don't document some -- you'd think -- pretty basic parts of their API, at least on the desktop. Case in point: just try to find out how to open up a raw socket on a selected network interface and you'll see what I mean. One shouldn't need to google for that. By "selected" network interface I mean you know the name like en0, but the interface has no IP or anything else.
And that comes from a guy who doesn't mind seeing legacy LISP code (like Maxima sources that I used to browse quite a bit), who doesn't mind various more- and less-pure functional languages (OCaml, Haskell) and functional "hacks" like LINQ, and who can wholeheartedly embrace "customizations" like xmos's XC parallellizable variant of C. I can even stand most of IEC 61131-3 languages. I guess beauty is in the eye of the beholder...
But it doesn't say precisely what that time is. It may be "long enough" as to be acceptable :)
I do agree that I was ahead of myself. Now for nitpicks:
Aerogel isn't a daydream. You can buy it. Costs reasonable amounts, even. If you wanted to insulate particularly hot CPU/GPU heatsinks in a laptop from the bottom of the case, a few mm of aerogel would be my choice, at a cost of maybe $10 or so. Maybe not in a $200 netbook, but Apple sure could pull that off if they needed to. Hot heatsinks are much easier to cool.
Superconductors are problematic due to rather theoretical reasons, too: good luck when you lose cooling (see what happened to LHC). Supercapacitors and low ESR don't mix. You get one or the other, and I think the reasons are to do with fundamental properties of the class of materials used in their design.
I don't really think that electric hybrids are very good at what they claim to do. Practical -- sure, but not very good at all. Unfortunately, neither are hydraulic hybrids, even 100% efficient ones, or really any other kind of hybrid, and I think that's where the buck stops.
But at least the theoretical limit is full efficiency. With most hybrid-electric systems, the theoretical limit is under 100% simply due to resistance of various parts of the circuit and chemical behavior of the batteries.
There are some pretty darn good insulators out there. Think aerogel -- heck, that one even has scalable price vs. performance. You chose density that you can afford (lower: more expensive), trading off performance for better price.