The first rule is: don't freak out. If you feel like freaking out is OK, then don't be a fucking pilot, mmkay? Pilots who freak out die. It's a time proven observation.
A pilot who doesn't know that the AoA and airspeed are sourced by the same set of vulnerable sensors is silly. Next time when you walk down the jetway have a look on your left before you enter the plane. You'll see the pitot tubes sticking out. As an engineer, they'd be the first things I'd distrust if their outputs would be in disagreement with other sensors. Icing happens all the time, it's more common than uncommon.
Those pilots had perfectly good input from the inertial platform, GPS and perhaps radio altimeter. They should have looked at their fine instruments, determined what their ground track speed was, what the attitude was, and figured out what to do. End of story.
Nope. You're mixing up partial oxygen pressure with gas mix ratio. The percentage of oxygen in the atmospheric air is pretty much same at sea level and at 8000ft. The partial pressure, dependent on total pressure, does affect combustion, though, as it does affect respiration, so you're right there. Yet the effect isn't all that significant when you start with something that's hard to set on fire anyway. Shoes are hard to set on fire, man.
If only that was possible. There are no parametric 3D CAD systems without DRM. There are no professional-grade EDA tools without DRM. For many devices, the only development environment has DRM and there are no third party alternatives.
I do the some with any EDA and development tools. They are all legitiate, but the first thing I do is get a crack for them so that I don't have to deal with the silliness. Who the heck wants to travel with a fistful of dongles in those times of checkpoint groping and think-of-the-children mentality.
And how exactly is Qt signal/slot system a "giant wave of bloat"? If you look at the code generated by the moc, it's not much different from what you'd do using GSignal, just that there's a tool that does the mundane for you. It's about all you can do without having real compiler support, so you need a LISP runtime, or a JVM or CLR to get it any less bloated.
I'm not sure what you mean by that; why would you recompile the runtime library?
VS11's C runtime is crippled not to run on anything below Vista SP2. They even crippled the linker to prevent marking the executable's subsystem version as compatible with XP, but at least it can be worked around by using editbin from a custom build step. Those are entirely arbitrary decisions with no technical reason other than forced abandonment of XP as a target for development.
But VS2010 already had a bunch of tasty C++11 stuff (and specifically lambdas!).
Sure. But if I'll spend the money, I might as well buy the newest version, why buy something that'll be a version behind as soon as VS11 hits RTM? It's time I moved to Windows 7 as my main virtual machine, that's not a problem, but I'll need to build for XP for at least 4-5 years.
Unless someone does the legwork of setting up project files needed to recompile C/C++ runtime library on VS11 (and fix it to work on XP), many people will be stuck with VS2010 as they have to target XP. I'm on VS2008, and I don't know yet if it's worth upgrading to 2010; I'd much rather go to VS11.
Whoa, hold on to your horses with your science oversimplification strawman. Sure we know all that about CO2, but we don't know what'll happen to it -- will it just sit there in the atmosphere? Will the changing climate affect how CO2 is released or absorbed by the oceans and the biosphere? Questions, questions, questions abound. Yes, surely a conservative approach is prudent, just in case everything was to go according to the direst predictions. Yet we can't claim it's anything more than willing to play it safe by default. We simply don't know any better.
That's a relatively newfangled thing, you know. There's tons of fairly recent code that couldn't use C++11, and said code, if pragmatically done, would use function objects for the price of source bloat and poor readability of the source code.
Umm, yes, a vector3 are three floats, what else would you want to put in there? C++ does type deletion so there's no overhead for a vector3 foo vs float foo[3]. Where did you get that eigen "advocates using a vector4 instead of vector3"? And do you have any results that show that optimizing for lowest possible cache misses, at all costs (you implied that, not me), leads to optimal performance? Code using eigen compiles to quite decent assembly; I dare you to show how it "performs terribly in real world usage due to appalling instruction cache usage". Are you actually using it, or just whining? They coax a C++ compiler into generating vectorized code, you won't get better performance by "simply" writing it in C (unless your C compiler is good at vectorization, and you're good at writing for that compiler).
It becomes a bit of a problem if a few lines of assembly turns into a monster, doesn't it? I mean, with the whole "high level language" thing, you'd think it should be easier, not harder, right?
Just look at those "dozen implementations". The C code almost universally requires some setjmp/longjmp functionality, while the compiler -- had it had computation-on-code a-la LISP -- could just as well take code of two coroutines and rewrite it so that it wouldn't require a separate stack frame. I am familiar with most coroutine and state machine implementations out there, and they universally suffer from basic limitations of the C model, the most major being that there's no straightforward compile-time computation, thus you can't use one set of data (or code) to generate arbitrary constant data structures and code snippets. Template metaprogramming in C++ is very limited because the compilers don't support realistic problem sizes (boost mpl is a toy just because of that). The hoops one has to jump through to provide lambda functionality in C++ is just icing on the cake:(
C-like languages, with exception of C#, make it impossible to implement some very common constructs that are trivial to do in assembly. Try implementing coroutines in C or C++.
I don't think that developers of eigen would agree with you. On the contrary, their works shows how using C++ can and does lead to higher performance without sacrificing programmer productivity.
I'm barely under 40, and even though I'm a mixed hardware/software person, we have a fabulous well-into-his-40s software engineer who does a superb job. We also have a guy in his mid-20s who isn't bad either, heck, he does software just for the fun of it. I look at some code that I wrote in my late teens and it's passable, but then I look at stuff I did when I was learning C++ in my 20s and I want to poke my eyes out...
Now for the intimate question: is that a bug or a feature that the lives counter condition check was signed:) The code was probably a decrement followed by jump on negative sign - you could play with 0 lives left, after all. A "proper" check would add two instructions - before it was, I guess, DEC lives; JS dead; after it would be MOV al, lives; OR al,al; JZ dead; DEC lives. No, I don't remember if MOV updates flags.
If you need more than 127 lives to get through that game, you're screwed anyway:) -- it was a simple solution to a simple problem. Agreed otherwise. I was maybe in 3rd or 4th grade at the time.
Ohh, I was lazier than that:) Montezuma Revenge on PC was coded in such a way, that when you searched for the byte with default number of lives (IIRC 3), it was before the 5th match that you'd hit the right byte to patch in the executable. No disassembly was involved. I'd patch the copy, run it, it'd crash or have a glitch, copy again, patch next location, and in IIRC 10 minutes I had 127 lives; IIRC the most significant bit couldn't be set. The key was not to get greedy: I initially tried incrementing the count only by one. Had I tried going directly to 255, I'd have never succeeded. I still remember it, even though it was 25+ years ago...
Slashdot Mirror
The first rule is: don't freak out. If you feel like freaking out is OK, then don't be a fucking pilot, mmkay? Pilots who freak out die. It's a time proven observation.
A pilot who doesn't know that the AoA and airspeed are sourced by the same set of vulnerable sensors is silly. Next time when you walk down the jetway have a look on your left before you enter the plane. You'll see the pitot tubes sticking out. As an engineer, they'd be the first things I'd distrust if their outputs would be in disagreement with other sensors. Icing happens all the time, it's more common than uncommon.
Those pilots had perfectly good input from the inertial platform, GPS and perhaps radio altimeter. They should have looked at their fine instruments, determined what their ground track speed was, what the attitude was, and figured out what to do. End of story.
How convenient of you to pretend that the oceans are not there. Oh, and the soil, although that probably plays a lesser role.
Thanks. You're right, of course. Give it 10 more years and it'll be probably useful. It seems it's where wine project was 10 years ago.
Nope. You're mixing up partial oxygen pressure with gas mix ratio. The percentage of oxygen in the atmospheric air is pretty much same at sea level and at 8000ft. The partial pressure, dependent on total pressure, does affect combustion, though, as it does affect respiration, so you're right there. Yet the effect isn't all that significant when you start with something that's hard to set on fire anyway. Shoes are hard to set on fire, man.
Oh, they can try all they want, it's entirely harmless.
Calling 8000ft altitutde a "low oxygen environment" isn't exactly clever, I don't think.
If only that was possible. There are no parametric 3D CAD systems without DRM. There are no professional-grade EDA tools without DRM. For many devices, the only development environment has DRM and there are no third party alternatives.
I do the some with any EDA and development tools. They are all legitiate, but the first thing I do is get a crack for them so that I don't have to deal with the silliness. Who the heck wants to travel with a fistful of dongles in those times of checkpoint groping and think-of-the-children mentality.
PS. Now, moderate that, ha.
And how exactly is Qt signal/slot system a "giant wave of bloat"? If you look at the code generated by the moc, it's not much different from what you'd do using GSignal, just that there's a tool that does the mundane for you. It's about all you can do without having real compiler support, so you need a LISP runtime, or a JVM or CLR to get it any less bloated.
Carbon cycle is not the only thing that can change the amount of atmospheric CO2, you know :)
I'm not sure what you mean by that; why would you recompile the runtime library?
VS11's C runtime is crippled not to run on anything below Vista SP2. They even crippled the linker to prevent marking the executable's subsystem version as compatible with XP, but at least it can be worked around by using editbin from a custom build step. Those are entirely arbitrary decisions with no technical reason other than forced abandonment of XP as a target for development.
But VS2010 already had a bunch of tasty C++11 stuff (and specifically lambdas!).
Sure. But if I'll spend the money, I might as well buy the newest version, why buy something that'll be a version behind as soon as VS11 hits RTM? It's time I moved to Windows 7 as my main virtual machine, that's not a problem, but I'll need to build for XP for at least 4-5 years.
Unless someone does the legwork of setting up project files needed to recompile C/C++ runtime library on VS11 (and fix it to work on XP), many people will be stuck with VS2010 as they have to target XP. I'm on VS2008, and I don't know yet if it's worth upgrading to 2010; I'd much rather go to VS11.
Sorry, no, that's not true at all.
Whoa, hold on to your horses with your science oversimplification strawman. Sure we know all that about CO2, but we don't know what'll happen to it -- will it just sit there in the atmosphere? Will the changing climate affect how CO2 is released or absorbed by the oceans and the biosphere? Questions, questions, questions abound. Yes, surely a conservative approach is prudent, just in case everything was to go according to the direst predictions. Yet we can't claim it's anything more than willing to play it safe by default. We simply don't know any better.
That's a relatively newfangled thing, you know. There's tons of fairly recent code that couldn't use C++11, and said code, if pragmatically done, would use function objects for the price of source bloat and poor readability of the source code.
Umm, yes, a vector3 are three floats, what else would you want to put in there? C++ does type deletion so there's no overhead for a vector3 foo vs float foo[3]. Where did you get that eigen "advocates using a vector4 instead of vector3"? And do you have any results that show that optimizing for lowest possible cache misses, at all costs (you implied that, not me), leads to optimal performance? Code using eigen compiles to quite decent assembly; I dare you to show how it "performs terribly in real world usage due to appalling instruction cache usage". Are you actually using it, or just whining? They coax a C++ compiler into generating vectorized code, you won't get better performance by "simply" writing it in C (unless your C compiler is good at vectorization, and you're good at writing for that compiler).
It becomes a bit of a problem if a few lines of assembly turns into a monster, doesn't it? I mean, with the whole "high level language" thing, you'd think it should be easier, not harder, right?
Just look at those "dozen implementations". The C code almost universally requires some setjmp/longjmp functionality, while the compiler -- had it had computation-on-code a-la LISP -- could just as well take code of two coroutines and rewrite it so that it wouldn't require a separate stack frame. I am familiar with most coroutine and state machine implementations out there, and they universally suffer from basic limitations of the C model, the most major being that there's no straightforward compile-time computation, thus you can't use one set of data (or code) to generate arbitrary constant data structures and code snippets. Template metaprogramming in C++ is very limited because the compilers don't support realistic problem sizes (boost mpl is a toy just because of that). The hoops one has to jump through to provide lambda functionality in C++ is just icing on the cake :(
C-like languages, with exception of C#, make it impossible to implement some very common constructs that are trivial to do in assembly. Try implementing coroutines in C or C++.
I don't think that developers of eigen would agree with you. On the contrary, their works shows how using C++ can and does lead to higher performance without sacrificing programmer productivity.
Just to be clear: I'm nowhere near "out of the field", heck, I'm learning new stuff all the time and it's exciting.
I'm barely under 40, and even though I'm a mixed hardware/software person, we have a fabulous well-into-his-40s software engineer who does a superb job. We also have a guy in his mid-20s who isn't bad either, heck, he does software just for the fun of it. I look at some code that I wrote in my late teens and it's passable, but then I look at stuff I did when I was learning C++ in my 20s and I want to poke my eyes out...
Agreed.
Statistics show that most software developers are out of the field by age 40.
So, is that a cause, or an effect, and what of, in any case? Yes, a pile of BS it is.
Now for the intimate question: is that a bug or a feature that the lives counter condition check was signed :) The code was probably a decrement followed by jump on negative sign - you could play with 0 lives left, after all. A "proper" check would add two instructions - before it was, I guess, DEC lives; JS dead; after it would be MOV al, lives; OR al,al; JZ dead; DEC lives. No, I don't remember if MOV updates flags.
If you need more than 127 lives to get through that game, you're screwed anyway :) -- it was a simple solution to a simple problem. Agreed otherwise. I was maybe in 3rd or 4th grade at the time.
Ohh, I was lazier than that :) Montezuma Revenge on PC was coded in such a way, that when you searched for the byte with default number of lives (IIRC 3), it was before the 5th match that you'd hit the right byte to patch in the executable. No disassembly was involved. I'd patch the copy, run it, it'd crash or have a glitch, copy again, patch next location, and in IIRC 10 minutes I had 127 lives; IIRC the most significant bit couldn't be set. The key was not to get greedy: I initially tried incrementing the count only by one. Had I tried going directly to 255, I'd have never succeeded. I still remember it, even though it was 25+ years ago...