SAE Level 2 in theory: A second set of eyes on the road, seeing the road in a different way as humans and with constant attention, is obviously an improvement over just one set of eyes on the road.
SAE Level 2 in practice, at least with some people: "Great, now I can use Twitter and Facebook during my commute!"
Same here. I've been talking about Tesla for years, and didn't own any Tesla stock until this spring, when Tesla fell down to $263. But after years and years of talking about it, I finally decided to put my money where my mouth was, as the short theses had gotten so ridiculous. Listening to them was often like listening to the Pizzagate crowd - just one silly conspiracy theory after the next.
Of course, I mention this fact in almost every thread on Tesla, so it should hardly be a surprise to anyone.;)
Look at Tesla's valuation. There is no possible way that it could ever be profitable enough to warrant such a valuation. Ever.
You forgot something: an argument to support your point.
Let me guess: it goes something like "look at how many cars they made in the past year vs. their valuation"?
Great, except that's not how you evaluate a company's value. A company's value is based on where they're going, relative to the risk in them getting there and the timeframes involved. In the case of Tesla, they're in the middle of a scaleup that no "competitors" are even close to matching. We're talking an order of magnitude difference in production rates. Other automakers have big longer term plans, but in the next couple years, Tesla stands alone. So at the very least one should be evaluating relative to that timeframe, accounting for the risk.
What Tesla is working towards in the next couple years isn't the hundred-thousand-ish cars per year of last year. It's the half million to 1-million ish, depending on how their schedule and capital flows go with Model Y timing and how much "Tesla Time Distortion Factor" you account for. Plus Semis. Plus a grid battery market growing at an order of magnitude per year. Plus a solar roofing product market, only just now going to its very first paying customers, that could become massive. They're simultaneously attacking multiple markets each in the hundreds of billions to trillions of dollars.
Now, if you're a Tesla bear, obviously you think they'll never get there. And that's fine, that's your view - you don't need to reiterate your talking points as to why you think they won't, we've heard them all a million times, just like you've heard our opposing ones. You surely likewise understand that bulls believe it's likely that they will get there. But regardless of whether one thinks they will or won't get there, they should have an appropriate sense of what the values of these markets are, in the case that Tesla does get there. They're massive. Which is why bulls feel that, even accounting for the risk, Tesla is well valued or undervalued.
It's the same situation with Amazon. Stupid Amazon bears looked at past revenues relative to spending. Smart Amazon bears looked at future revenue potential, but just didn't believe they'd get there. Amazon bulls looked at future revenue potential, and did believe they'd get there. Amazon got there, the bulls profited, and both the stupid and smart bears lost. But at least the smart bears had a plausible argument.
And that's how the cycle goes. Someone posts a hit piece, everyone sees it, the fact come out later, and almost nobody sees them.
The reality (which one might have guessed from the original article in that some of the suppliers contacted by WSJ had never heard of the request) turned out to be that:
1) There were fewer than 10 suppliers that were contacted by Tesla.
2) They were not concerning past contracts; they were concerning ongoing contracts. While it may not seem fair, automakers using their bully pulpit to renegotiate with suppliers for ongoing contracts is standard industry practice.
3) These were not concerning parts suppliers; these were suppliers contracted with Tesla on capex projects.
4) None of these things will affect the Q3 profits picture.
The Model 3's approach is to put all of the most common functions on the steering wheel controls. The next most common functions - and most common things to see - are on the far left of the screen, right beside the wheel, so right next to your right hand, or right along the bottom rim. Note that it's a 16:9 15" screen (aka 33cm width) with 11 square buttons across. Meaning that each button is 3x3cm. These are not small controls by any stretch, and they're immediately adjacent to a rim, acting as a guideline.
(Note: to anyone who's never driven a car with a central speedometer: you're predominantly looking "down" either way. The only difference is that with a central speedometer - not even that Model 3's is all that central - you're also looking somewhat to the right. The advantage is that it's never blocked by the steering wheel or your hands, and that the dash can be lowered in front of the driver).
As for the specific case of air conditioning: it's a control larger than a credit card, right next to your right hand, so if you can't see that and hit in your peripheral vision, something's wrong with you.
As I've written elsewhere, there’s actually some very good reasons for the way the air vents are. First off, the big one: you have to be able to reach any controls in the car as a driver. So if your controls for your air vents are on the air vents, that means that they must be within reach of a comfortable driving position. Which means that the dash has to be so far forward that you can reach them. By having electronic controls for the vents, they can move the dash back and down, which improves ingress/egress and forward visibility.
Having electronically controlled vents means that they can make the outflow for the vent much larger. The larger the outflow, the quieter the airflow for a given flow volume, and the higher the peak flow volume you can achieve.
Electronically controlled vents means that vents can be autoadjusted to driver profiles. So whatever the current driver likes can be automatically set when said driver sits down. And there’s the potential for other features in the future — for example, someone pointed out to Musk (the idea seemed well received, so we may see it ~6 months from now) that when one turns on the air conditioning remotely, the vents should autoaim at the seats to cool them down.
Lastly, you have the fact that you can adjust multiple vents at the same time, with the vent-ganging functionality.
I will however add... I do feel bad for the guy. I couldn't agree with him less, and he's taken part in a pretty shameful amount of trolling over the years (particularly his recent efforts to drive away Dan Neil and subsequent gloating). But I don't want to see anyone - yes, even trolls - get in trouble for expressing their views online. I don't think there was some grand conspiracy paying him to post as he was - I think that's just his ideology.
Be aware that Montana Skeptic - famous for spinning conspiracy theories about Tesla and Musk that turn out not to be true - has given two conflictingexplanations for why he deleted his Twitter account. In one of them, it had nothing to do with Musk, and in the other, it's all evil Elon's fault.
1) Montana Skeptic has (via intermediaries) presented two entirely different scenarios for why he left Twitter. One was that he was just leaving to spend more time focused on his investments, and it had nothing to do with outside pressure. The other is that Musk called his boss and his boss made him quit. Given his penchant for spinning conspiracy theories... take whichever one you want with a grain of salt.
2) There's a heavy dose of irony, in that just a few days ago Montana Skeptic was part of the troll attacks against Pulitzer-prize winning auto journalist Dan Neil (mad that he wrote a glowing review of the Model 3 in the Wall Street Journal) which ultimately led to Dan deleting his twitter account. He wrote a gloating post after they succeeded, which is kind of funny in light of recent events.
3) Fun Fact: Fossi (aka Montana Skeptic)'s employer is Stewart Rahl - a guy often described as Trump's only true friend, inflappably loyal. His office is in Trump Tower, two floors below Trump's.
Normal Earth air. Both nitrogen and oxygen are lifting gases on Venus.
Try building one on earth first.
That would be a prototyping step, yes. Just like Mars habitats are also first tested on Earth. On Earth, however, you'd have to use heliox as the lifting gas.
Venus has a much harsher atmosphere and is literally raining acid.
Actually 1) we don't know whether there's any sulfuric acid rains, snows or frosts in Venus's middle cloud layer, and B) it would actually be preferable if they were there!
There's no shortage of polymers that can withstand sulfuric acid well (particularly, although not exclusively, fluoropolymers). Sulfuric acid, however, is a huge resource on Venus. It's the primary available source of hydrogen, and extremely easy to decompose into useful resources. Simple heating first off drives off free water. Further heating decomposes H2SO4 into SO3 and more H2O. Further heating of SO3 over a vanadium catalyst yields SO2 + O2. Contrarily, the SO3 can be used as a conditioning agent in the scrubber for nucleating more H2SO4 and capturing free H2O.
The main disadvantage of sulfuric acid in Venus's middle cloud layer is that there just isn't that much of it! It's more like a bad smog (or more accurately, vog). Visibility can be several kilometers, it's that sparse. You have to process a lot of air to get the hydrogen you need for ascent vehicle propellant.
You can launch garbage toward the sun with a homemade water rocket. It's getting to the sun that's difficult. It takes more dV to get to the sun via a direct Hohmann transfer than it does to leave the solar system entirely.
Venus would be a great destination for nuclear thermal, and an excuse to develop the tech to a point that people could be more comfortable with using it on Earth. You still have to launch nuclear fuel from Earth, of course, but just as a payload, not in the form of a operating, short-lived-isotope-generating reactor. People could rest easy knowing that the only time it would be turned on would be in the atmosphere / orbit of an entirely different planet. Of course, once you've had such a rocket working on another planet for years without incident, the question would arise... why not Earth?
It would be exceedingly useful as an ascent vehicle for a Landis-style (floating, breathable-air-lofted) Venus habitat. While the need for using a light gas as propellant makes pure hydrogen the only realistic option for nuclear thermal, and hydrogen is in relatively limited supply in Venus's atmosphere, the extreme fuel efficiency of nuclear thermal rockets (and in particular the airbreathing hybrid variants) means that you just don't need that much of it - less than all but the most hydrogen-sparing of chemical propellant options (such the hydrogen-free LOX-CO or LOX-C2N2 combinations... although even they're best with a bit of methane or H2 in the mix). It also means that the ascent stage can be vastly lighter when fully fueled, allowing for far more human/water/crop mass inside a given habitat rather than dedicating ~90% of the habitat's lift to lofting a fueled ascent stage. Lastly, some nuclear thermal designs involve compressors and can effectively hover indefinitely - eliminating the need*** for returning stages to be balloon-lofted during docking to the habitat's underside.
You certainly can also use a nuclear thermal rocket on Mars as well - not just Venus - but it's not nearly so essential. It's a lot easier to get off of Mars' surface with chemical rockets than it is out of Venus's atmosphere - even directly landing your Earth-Mars transfer stage (as in the case of BFR). With Venus, realistically you need at least two stages for a chemical-powered ascent vehicle, and the payload fraction is low. And you have to re-mate the stages - each docked individually - while they're hanging from the underside of the habitat.
*** It's technically possible to have a SpaceX-style platform landing, but extremely difficult. If the platform is on the top of the habitat, the platform has to be able to hold an extremely heavy rocket (large chunk of the total habitat's mass) without flipping it over. If the platform is hanging from the bottom, you need a lot of clearance - and in either regard, a huge amount of structural strength on the platform, yet with strict mass limits. The failure modes on this sort of landing/docking are also a lot more severe than with balloons (which reenter further away from the habitat). You have as much "go-around" time as you want with a balloon, and are never going to accidentally send a returning stage crashing through the habitat at hundreds of meters per second; you just have the habitat approach from well above and use a tethered drone to mate the two together. Balloon-lofted returning stages have been investigated before for use on Earth (and ballutes have been used for deceleration of returning spacecraft), but never implemented.
Enums are treated as ints under the covers. Depending on your compiler flags, enums / ints should automatically cast to char:
enum e {
FOO = 0,
BAR = 1 };
int main(int argc, char** argv) {
char c;
c = FOO;
return 0; }
No warnings with default g++ compiler flags.
I have only limited knowledge about Python, but memory problems never were an issue.
And I've encountered python memory and performance roadblocks which are difficult or impossible to resolve frequently. Just because you don't do memory or CPU intensive tasks doesn't mean that nobody does.
If I care about memory, I'll just store it as a char or unsigned char. And that's the key difference: in C/C++, you have easy and full control over memory usage. In Python, you have to jump through hoops, where it's even possible at all.
it only matters for members of structs when you allocate huge amounts of such structs
And maybe you never do that, but many people, including myself, do.
As an example of why I used a threadsafe map... I was working on a ring network, and had a ring of nodes. It was built around a std::map so that you could seek to each individual node directly by their hex ID (std::map::find() or []); so that the closest node to a target hex could be found (with upper_bound()/lower_bound()); and so that you could iterate through a node's neighbors.
Various threads could add or remove elements in the ring at any point in time, and there were many tasks that involved iterating through every element of the ring in order. Also, sometimes there would be tasks where a node would need to iterate through its neighbors in either direction. So you can imagine the disaster that happens when you've got an iterator pointing to something that just disappears on it (also there can be problems with begin()/end() nodes). But locking the entire network for the entire duration of a cross-network sweep (with significant per-node overhead) was also not an option, and there was meaningful overhead to seek operations, so it was really desirable to be able to iterate through neighbors.
The threadsafe map class really did the trick for me (I was also able to give it a mode to allow for circular iteration, which std::map doesn't have... aka you go off one end and come back in on the other). I had to replace the std::map iterators with a wrapper class that acted as smart pointers to the nodes, and nodes (also wrapped) couldn't be physically deleted until there were no longer any iterator references to them. A deletion operation merely flagged a given node for deletion. And of course I had to put locks / lock guards around all of the std::map functions that weren't overridden.
One piece of unexpected behavior was the realization that reverse iterators have gotchas. If you have a forward iterator to an element of a std::map and you insert an element elsewhere in the map, nothing happens, no matter where it was inserted; your iterator continues pointing to the exact same element it had been pointing to. But reverse iterators actually point to one beyond the element that they appear to point to, so insertions can cause what your iterator points to to change. I had to write my own reverse iterator implementation because that sort of behavior totally blows up in a threaded environment.
It depends entirely on what you want to do. In C/C++, you set your variables to the type you need. In python, they're always huge. E.g. I don't need an int64 to keep track of what's basically an enum, or whatnot.
Python really becomes a memory monster once you do multidimensional data structures. And numpy just isn't that flexible with them, so you're often forced into using native python data structures.
Lol... now I'm reading through old code... apparently every male character's fozzle had a hard-coded length (0-9), which was randomized based on their name. Except for user "timster", whose fozzle length was hardcoded to "700";) I think I added that in to stop him from complaining about my new body part / combat system, lol.
Man, I went way further with this than I remember... there's code in here where if you take too many blows to the head, it messes with your sanity, so that you can end up wandering aimlessly and the like. Injuries can mess with your ability to digest food, metabolize alcohol, vision, hearing, balance, sex drive, everything.
Now I'm looking at the code behind rooms... most people's rooms were a couple hundred bytes, up to a couple K. My average room size was ~30K due to all of the code in them;) To the point where if the description used a metaphor, and you tried to treat it as literal, it might threaten to sick the "Gods of Literality" on you, and if you persisted, would actually do so. Nethack-levels of detail.:)
It was an apocalyptic themed MUD, and I had the town slowly become more twisted and evil the closer it got to the reset. All NPCs had a function to be updated as to the progression of the apocalypse over time, and increasingly go insane.
There was a bakery, and you could pass the baker random objects to bake into a bread. Randomized based on the given object's name, it might give the bread an effect when eaten... usually minor and insignificant, sometimes poisonous, but rarely really weird. It could make you incapable of using complicated words or handling complicated sentences and speak with a lisp. It could turn you evil - swapping out random innocent action commands with things like love->kill, hug->bite, agree->disagree, etc. It could scramble the words in your sentences, or weld your lips together so you can only mumble, or make you stutter. It could make you randomly wander aimlessly. All sorts of things.
My biggest fault was going overboard on very specific things. For example, I always thought that the whole notion of "hitpoints" was too simplistic and not realistic. I mean, that's not how people get injured in real life! But the more I started trying to "improve" it, the more complicated it got. By the end, you had blood levels, and a bleed rate based on wounds you had received, with the bleed rate slowly declining over time and blood slowly recovering. You had limbs, depending on what type of creature you had, with different probabilities of being hit, and with the ability to be damaged (interfering with various player functions) or severed outright (slowly regenerating, unless a fatal hit). Players could just go with a random attack, or choose to target specific body parts (with a lower probability of hit). It was even taking gender into account in determining body parts... although to keep it "clean", body parts were renamed (if I recall correctly, men had a "fozzle").
Basically, it just got way too complicated, way too quickly.
I loved coding for LP muds. They weren't so much a "multiplayer notepad" as you could have true C-ish code running behind the scenes. LPC was a great language, in that you could physically interact with your objects. You could carry around a class in your inventory. Randomly call functions on it. Have other peoples' actions trigger functions. It opened up so many possibilities.
The best were "Wizard (admin) Duels", which was basically warfare between programmers. It was common for wizards to write "dests", which destructed a person's player object to (briefly) kick them out of the game. These often involved elaborate broadcast leadups describing what they were doing and what was happening to the victim. One wizard kept desting me, so I wrote an instant counterdest that I could call that would dest him first. So he sped up his dest so that I wouldn't have time. So I had mine detect that his dest was going off automatically and autodest him. So he made his instant. So I made an object that would hop into his inventory and intercept his dest command, and dest himself instead. But then I had to be paranoid about him making objects to hop into my inventory, so I made an inventory-protector that monitored my person and the room I'm in for "suspicious" objects to destruct. On and on it went.
The screwups could be glorious, too. At one point during the coding of my inventory protector, I messed up and it accidentally dested me. It then fell to the floor in the login room and dested everyone else in there. And anyone who logged in would then get insta-dested by it. I had accidentally created a killbot run amock;) We had no access to the server to reboot it, and almost everyone had gotten kicked off by it... except for one wizard operating in a different room. But since we couldn't log in, we had no way to contact him. Until I came up with an idea. We uploaded files to the MUD via FTP, so I uploaded a file to his home directory with the title, "(HISNAME)_PLEASE_READ_ME_NOW.txt", which explained the situation and how to fix it. Sure enough, 15 minutes later, he notices the file, reads it, and destroys my inadverent-killbot so we can all log back in.;)
You just don't get those sorts of experiences anymore.
Python is great because you can write something and there's almost no startup overhead - you just start shoving whatever data into whatever variables you want without having to define classes / structures, pass whatever you want without having to define types, etc - and it's got a great set of packages to work with. You get "out of the gate" a lot faster. But then it nickels and dimes you after that point due to the memory/performance overhead. And trying to work around Python's internal limitations means a lot of programming overhead. Also, the non-typesafe nature of Python - again, while convenient in initial programming - also tends to hide bugs. Again, things are easier for you earlier on, harder later on.
Often (particularly for simple programs), Python is the right choice and can save you a lot of time. But if you're unlucky, it can cost you a even more time.
The new C++ standards help get rid of a lot of the old C++ annoyances and greatly increase the power of stl. You can have as tight memory and performance as you want. You still have to lay out all of your structures and types, so your "startup times" are longer. But it's so dang powerful after that point. There's still some things they need to tackle, mind you - IMHO strings are still a mess, they need a std::utf8_string, with std::string intended only for 1-byte characters, and IMHO std::wstring should be obsoleted because utf16 is inherently dangerous (it'll "usually" work, and so pass testing, but then someone will input a 4-byte character and everything explodes). But in general.... C++ has really matured. In particular, I love smart pointers, and I so love the combination of std::thread and lambdas in order to inline threaded statements (although they need to add threadsafe stl classes... I had to write a threadsafe std::map with threadsafe iterators for one project I was working on).
Maybe I'm more prone to have my programming projects involve data crunching than the average person.
Python is great for a "whip it together quickly" project. Even with data crunching, some slowdown, and gobbling up half your memory, is fine. But push it too far, and everything falls apart gloriously. And knowing in advance whether you'll hit that bound is not always obvious. If I know from the beginning something will be a big project, I start it in C++.
Slashdot Mirror
Humanity strikes again.
SAE Level 2 in theory: A second set of eyes on the road, seeing the road in a different way as humans and with constant attention, is obviously an improvement over just one set of eyes on the road.
SAE Level 2 in practice, at least with some people: "Great, now I can use Twitter and Facebook during my commute!"
Same here. I've been talking about Tesla for years, and didn't own any Tesla stock until this spring, when Tesla fell down to $263. But after years and years of talking about it, I finally decided to put my money where my mouth was, as the short theses had gotten so ridiculous. Listening to them was often like listening to the Pizzagate crowd - just one silly conspiracy theory after the next.
Of course, I mention this fact in almost every thread on Tesla, so it should hardly be a surprise to anyone. ;)
You forgot something: an argument to support your point.
Let me guess: it goes something like "look at how many cars they made in the past year vs. their valuation"?
Great, except that's not how you evaluate a company's value. A company's value is based on where they're going, relative to the risk in them getting there and the timeframes involved. In the case of Tesla, they're in the middle of a scaleup that no "competitors" are even close to matching. We're talking an order of magnitude difference in production rates. Other automakers have big longer term plans, but in the next couple years, Tesla stands alone. So at the very least one should be evaluating relative to that timeframe, accounting for the risk.
What Tesla is working towards in the next couple years isn't the hundred-thousand-ish cars per year of last year. It's the half million to 1-million ish, depending on how their schedule and capital flows go with Model Y timing and how much "Tesla Time Distortion Factor" you account for. Plus Semis. Plus a grid battery market growing at an order of magnitude per year. Plus a solar roofing product market, only just now going to its very first paying customers, that could become massive. They're simultaneously attacking multiple markets each in the hundreds of billions to trillions of dollars.
Now, if you're a Tesla bear, obviously you think they'll never get there. And that's fine, that's your view - you don't need to reiterate your talking points as to why you think they won't, we've heard them all a million times, just like you've heard our opposing ones. You surely likewise understand that bulls believe it's likely that they will get there. But regardless of whether one thinks they will or won't get there, they should have an appropriate sense of what the values of these markets are, in the case that Tesla does get there. They're massive. Which is why bulls feel that, even accounting for the risk, Tesla is well valued or undervalued.
It's the same situation with Amazon. Stupid Amazon bears looked at past revenues relative to spending. Smart Amazon bears looked at future revenue potential, but just didn't believe they'd get there. Amazon bulls looked at future revenue potential, and did believe they'd get there. Amazon got there, the bulls profited, and both the stupid and smart bears lost. But at least the smart bears had a plausible argument.
Ed: the facts come out later. Maybe some day Slashdot will move at least into the '00s and add an edit feature. :P
And that's how the cycle goes. Someone posts a hit piece, everyone sees it, the fact come out later, and almost nobody sees them.
The reality (which one might have guessed from the original article in that some of the suppliers contacted by WSJ had never heard of the request) turned out to be that:
1) There were fewer than 10 suppliers that were contacted by Tesla.
2) They were not concerning past contracts; they were concerning ongoing contracts. While it may not seem fair, automakers using their bully pulpit to renegotiate with suppliers for ongoing contracts is standard industry practice.
3) These were not concerning parts suppliers; these were suppliers contracted with Tesla on capex projects.
4) None of these things will affect the Q3 profits picture.
The Model 3's approach is to put all of the most common functions on the steering wheel controls. The next most common functions - and most common things to see - are on the far left of the screen, right beside the wheel, so right next to your right hand, or right along the bottom rim. Note that it's a 16:9 15" screen (aka 33cm width) with 11 square buttons across. Meaning that each button is 3x3cm. These are not small controls by any stretch, and they're immediately adjacent to a rim, acting as a guideline.
(Note: to anyone who's never driven a car with a central speedometer: you're predominantly looking "down" either way. The only difference is that with a central speedometer - not even that Model 3's is all that central - you're also looking somewhat to the right. The advantage is that it's never blocked by the steering wheel or your hands, and that the dash can be lowered in front of the driver).
As for the specific case of air conditioning: it's a control larger than a credit card, right next to your right hand, so if you can't see that and hit in your peripheral vision, something's wrong with you.
As I've written elsewhere, there’s actually some very good reasons for the way the air vents are. First off, the big one: you have to be able to reach any controls in the car as a driver. So if your controls for your air vents are on the air vents, that means that they must be within reach of a comfortable driving position. Which means that the dash has to be so far forward that you can reach them. By having electronic controls for the vents, they can move the dash back and down, which improves ingress/egress and forward visibility.
Having electronically controlled vents means that they can make the outflow for the vent much larger. The larger the outflow, the quieter the airflow for a given flow volume, and the higher the peak flow volume you can achieve.
Electronically controlled vents means that vents can be autoadjusted to driver profiles. So whatever the current driver likes can be automatically set when said driver sits down. And there’s the potential for other features in the future — for example, someone pointed out to Musk (the idea seemed well received, so we may see it ~6 months from now) that when one turns on the air conditioning remotely, the vents should autoaim at the seats to cool them down.
Lastly, you have the fact that you can adjust multiple vents at the same time, with the vent-ganging functionality.
*Cough*
I will however add... I do feel bad for the guy. I couldn't agree with him less, and he's taken part in a pretty shameful amount of trolling over the years (particularly his recent efforts to drive away Dan Neil and subsequent gloating). But I don't want to see anyone - yes, even trolls - get in trouble for expressing their views online. I don't think there was some grand conspiracy paying him to post as he was - I think that's just his ideology.
Be aware that Montana Skeptic - famous for spinning conspiracy theories about Tesla and Musk that turn out not to be true - has given two conflicting explanations for why he deleted his Twitter account. In one of them, it had nothing to do with Musk, and in the other, it's all evil Elon's fault.
1) Montana Skeptic has (via intermediaries) presented two entirely different scenarios for why he left Twitter. One was that he was just leaving to spend more time focused on his investments, and it had nothing to do with outside pressure. The other is that Musk called his boss and his boss made him quit. Given his penchant for spinning conspiracy theories... take whichever one you want with a grain of salt.
2) There's a heavy dose of irony, in that just a few days ago Montana Skeptic was part of the troll attacks against Pulitzer-prize winning auto journalist Dan Neil (mad that he wrote a glowing review of the Model 3 in the Wall Street Journal) which ultimately led to Dan deleting his twitter account. He wrote a gloating post after they succeeded, which is kind of funny in light of recent events.
3) Fun Fact: Fossi (aka Montana Skeptic)'s employer is Stewart Rahl - a guy often described as Trump's only true friend, inflappably loyal. His office is in Trump Tower, two floors below Trump's.
Normal Earth air. Both nitrogen and oxygen are lifting gases on Venus.
That would be a prototyping step, yes. Just like Mars habitats are also first tested on Earth. On Earth, however, you'd have to use heliox as the lifting gas.
Actually 1) we don't know whether there's any sulfuric acid rains, snows or frosts in Venus's middle cloud layer, and B) it would actually be preferable if they were there!
There's no shortage of polymers that can withstand sulfuric acid well (particularly, although not exclusively, fluoropolymers). Sulfuric acid, however, is a huge resource on Venus. It's the primary available source of hydrogen, and extremely easy to decompose into useful resources. Simple heating first off drives off free water. Further heating decomposes H2SO4 into SO3 and more H2O. Further heating of SO3 over a vanadium catalyst yields SO2 + O2. Contrarily, the SO3 can be used as a conditioning agent in the scrubber for nucleating more H2SO4 and capturing free H2O.
The main disadvantage of sulfuric acid in Venus's middle cloud layer is that there just isn't that much of it! It's more like a bad smog (or more accurately, vog). Visibility can be several kilometers, it's that sparse. You have to process a lot of air to get the hydrogen you need for ascent vehicle propellant.
Like this.
If you first tell him to shove a rocket up his arse like the diver did? Maybe. Go try.
You can launch garbage toward the sun with a homemade water rocket. It's getting to the sun that's difficult. It takes more dV to get to the sun via a direct Hohmann transfer than it does to leave the solar system entirely.
Venus would be a great destination for nuclear thermal, and an excuse to develop the tech to a point that people could be more comfortable with using it on Earth. You still have to launch nuclear fuel from Earth, of course, but just as a payload, not in the form of a operating, short-lived-isotope-generating reactor. People could rest easy knowing that the only time it would be turned on would be in the atmosphere / orbit of an entirely different planet. Of course, once you've had such a rocket working on another planet for years without incident, the question would arise... why not Earth?
It would be exceedingly useful as an ascent vehicle for a Landis-style (floating, breathable-air-lofted) Venus habitat. While the need for using a light gas as propellant makes pure hydrogen the only realistic option for nuclear thermal, and hydrogen is in relatively limited supply in Venus's atmosphere, the extreme fuel efficiency of nuclear thermal rockets (and in particular the airbreathing hybrid variants) means that you just don't need that much of it - less than all but the most hydrogen-sparing of chemical propellant options (such the hydrogen-free LOX-CO or LOX-C2N2 combinations... although even they're best with a bit of methane or H2 in the mix). It also means that the ascent stage can be vastly lighter when fully fueled, allowing for far more human/water/crop mass inside a given habitat rather than dedicating ~90% of the habitat's lift to lofting a fueled ascent stage. Lastly, some nuclear thermal designs involve compressors and can effectively hover indefinitely - eliminating the need*** for returning stages to be balloon-lofted during docking to the habitat's underside.
You certainly can also use a nuclear thermal rocket on Mars as well - not just Venus - but it's not nearly so essential. It's a lot easier to get off of Mars' surface with chemical rockets than it is out of Venus's atmosphere - even directly landing your Earth-Mars transfer stage (as in the case of BFR). With Venus, realistically you need at least two stages for a chemical-powered ascent vehicle, and the payload fraction is low. And you have to re-mate the stages - each docked individually - while they're hanging from the underside of the habitat.
*** It's technically possible to have a SpaceX-style platform landing, but extremely difficult. If the platform is on the top of the habitat, the platform has to be able to hold an extremely heavy rocket (large chunk of the total habitat's mass) without flipping it over. If the platform is hanging from the bottom, you need a lot of clearance - and in either regard, a huge amount of structural strength on the platform, yet with strict mass limits. The failure modes on this sort of landing/docking are also a lot more severe than with balloons (which reenter further away from the habitat). You have as much "go-around" time as you want with a balloon, and are never going to accidentally send a returning stage crashing through the habitat at hundreds of meters per second; you just have the habitat approach from well above and use a tethered drone to mate the two together. Balloon-lofted returning stages have been investigated before for use on Earth (and ballutes have been used for deceleration of returning spacecraft), but never implemented.
Enums are treated as ints under the covers. Depending on your compiler flags, enums / ints should automatically cast to char:
No warnings with default g++ compiler flags.
And I've encountered python memory and performance roadblocks which are difficult or impossible to resolve frequently. Just because you don't do memory or CPU intensive tasks doesn't mean that nobody does.
If I care about memory, I'll just store it as a char or unsigned char. And that's the key difference: in C/C++, you have easy and full control over memory usage. In Python, you have to jump through hoops, where it's even possible at all.
And maybe you never do that, but many people, including myself, do.
I'm going to have to stop you right there; the current preferred term is "Feminazgûl". Our slogan: "The World Of Men Will Fall".
We're also made of straw.
As an example of why I used a threadsafe map... I was working on a ring network, and had a ring of nodes. It was built around a std::map so that you could seek to each individual node directly by their hex ID (std::map::find() or []); so that the closest node to a target hex could be found (with upper_bound()/lower_bound()); and so that you could iterate through a node's neighbors.
Various threads could add or remove elements in the ring at any point in time, and there were many tasks that involved iterating through every element of the ring in order. Also, sometimes there would be tasks where a node would need to iterate through its neighbors in either direction. So you can imagine the disaster that happens when you've got an iterator pointing to something that just disappears on it (also there can be problems with begin()/end() nodes). But locking the entire network for the entire duration of a cross-network sweep (with significant per-node overhead) was also not an option, and there was meaningful overhead to seek operations, so it was really desirable to be able to iterate through neighbors.
The threadsafe map class really did the trick for me (I was also able to give it a mode to allow for circular iteration, which std::map doesn't have... aka you go off one end and come back in on the other). I had to replace the std::map iterators with a wrapper class that acted as smart pointers to the nodes, and nodes (also wrapped) couldn't be physically deleted until there were no longer any iterator references to them. A deletion operation merely flagged a given node for deletion. And of course I had to put locks / lock guards around all of the std::map functions that weren't overridden.
One piece of unexpected behavior was the realization that reverse iterators have gotchas. If you have a forward iterator to an element of a std::map and you insert an element elsewhere in the map, nothing happens, no matter where it was inserted; your iterator continues pointing to the exact same element it had been pointing to. But reverse iterators actually point to one beyond the element that they appear to point to, so insertions can cause what your iterator points to to change. I had to write my own reverse iterator implementation because that sort of behavior totally blows up in a threaded environment.
It depends entirely on what you want to do. In C/C++, you set your variables to the type you need. In python, they're always huge. E.g. I don't need an int64 to keep track of what's basically an enum, or whatnot.
Python really becomes a memory monster once you do multidimensional data structures. And numpy just isn't that flexible with them, so you're often forced into using native python data structures.
Ah, good ol' 3k. Wonder how many months of playtime I had on that one....
Lol... now I'm reading through old code... apparently every male character's fozzle had a hard-coded length (0-9), which was randomized based on their name. Except for user "timster", whose fozzle length was hardcoded to "700" ;) I think I added that in to stop him from complaining about my new body part / combat system, lol.
Man, I went way further with this than I remember... there's code in here where if you take too many blows to the head, it messes with your sanity, so that you can end up wandering aimlessly and the like. Injuries can mess with your ability to digest food, metabolize alcohol, vision, hearing, balance, sex drive, everything.
Now I'm looking at the code behind rooms... most people's rooms were a couple hundred bytes, up to a couple K. My average room size was ~30K due to all of the code in them ;) To the point where if the description used a metaphor, and you tried to treat it as literal, it might threaten to sick the "Gods of Literality" on you, and if you persisted, would actually do so. Nethack-levels of detail. :)
It was an apocalyptic themed MUD, and I had the town slowly become more twisted and evil the closer it got to the reset. All NPCs had a function to be updated as to the progression of the apocalypse over time, and increasingly go insane.
There was a bakery, and you could pass the baker random objects to bake into a bread. Randomized based on the given object's name, it might give the bread an effect when eaten... usually minor and insignificant, sometimes poisonous, but rarely really weird. It could make you incapable of using complicated words or handling complicated sentences and speak with a lisp. It could turn you evil - swapping out random innocent action commands with things like love->kill, hug->bite, agree->disagree, etc. It could scramble the words in your sentences, or weld your lips together so you can only mumble, or make you stutter. It could make you randomly wander aimlessly. All sorts of things.
Man, this stuff was fun to write...
My biggest fault was going overboard on very specific things. For example, I always thought that the whole notion of "hitpoints" was too simplistic and not realistic. I mean, that's not how people get injured in real life! But the more I started trying to "improve" it, the more complicated it got. By the end, you had blood levels, and a bleed rate based on wounds you had received, with the bleed rate slowly declining over time and blood slowly recovering. You had limbs, depending on what type of creature you had, with different probabilities of being hit, and with the ability to be damaged (interfering with various player functions) or severed outright (slowly regenerating, unless a fatal hit). Players could just go with a random attack, or choose to target specific body parts (with a lower probability of hit). It was even taking gender into account in determining body parts... although to keep it "clean", body parts were renamed (if I recall correctly, men had a "fozzle").
Basically, it just got way too complicated, way too quickly.
I loved coding for LP muds. They weren't so much a "multiplayer notepad" as you could have true C-ish code running behind the scenes. LPC was a great language, in that you could physically interact with your objects. You could carry around a class in your inventory. Randomly call functions on it. Have other peoples' actions trigger functions. It opened up so many possibilities.
The best were "Wizard (admin) Duels", which was basically warfare between programmers. It was common for wizards to write "dests", which destructed a person's player object to (briefly) kick them out of the game. These often involved elaborate broadcast leadups describing what they were doing and what was happening to the victim. One wizard kept desting me, so I wrote an instant counterdest that I could call that would dest him first. So he sped up his dest so that I wouldn't have time. So I had mine detect that his dest was going off automatically and autodest him. So he made his instant. So I made an object that would hop into his inventory and intercept his dest command, and dest himself instead. But then I had to be paranoid about him making objects to hop into my inventory, so I made an inventory-protector that monitored my person and the room I'm in for "suspicious" objects to destruct. On and on it went.
The screwups could be glorious, too. At one point during the coding of my inventory protector, I messed up and it accidentally dested me. It then fell to the floor in the login room and dested everyone else in there. And anyone who logged in would then get insta-dested by it. I had accidentally created a killbot run amock ;) We had no access to the server to reboot it, and almost everyone had gotten kicked off by it... except for one wizard operating in a different room. But since we couldn't log in, we had no way to contact him. Until I came up with an idea. We uploaded files to the MUD via FTP, so I uploaded a file to his home directory with the title, "(HISNAME)_PLEASE_READ_ME_NOW.txt", which explained the situation and how to fix it. Sure enough, 15 minutes later, he notices the file, reads it, and destroys my inadverent-killbot so we can all log back in. ;)
You just don't get those sorts of experiences anymore.
Love C++17.
Python is great because you can write something and there's almost no startup overhead - you just start shoving whatever data into whatever variables you want without having to define classes / structures, pass whatever you want without having to define types, etc - and it's got a great set of packages to work with. You get "out of the gate" a lot faster. But then it nickels and dimes you after that point due to the memory/performance overhead. And trying to work around Python's internal limitations means a lot of programming overhead. Also, the non-typesafe nature of Python - again, while convenient in initial programming - also tends to hide bugs. Again, things are easier for you earlier on, harder later on.
Often (particularly for simple programs), Python is the right choice and can save you a lot of time. But if you're unlucky, it can cost you a even more time.
The new C++ standards help get rid of a lot of the old C++ annoyances and greatly increase the power of stl. You can have as tight memory and performance as you want. You still have to lay out all of your structures and types, so your "startup times" are longer. But it's so dang powerful after that point. There's still some things they need to tackle, mind you - IMHO strings are still a mess, they need a std::utf8_string, with std::string intended only for 1-byte characters, and IMHO std::wstring should be obsoleted because utf16 is inherently dangerous (it'll "usually" work, and so pass testing, but then someone will input a 4-byte character and everything explodes). But in general.... C++ has really matured. In particular, I love smart pointers, and I so love the combination of std::thread and lambdas in order to inline threaded statements (although they need to add threadsafe stl classes... I had to write a threadsafe std::map with threadsafe iterators for one project I was working on).
Maybe I'm more prone to have my programming projects involve data crunching than the average person.
Python is great for a "whip it together quickly" project. Even with data crunching, some slowdown, and gobbling up half your memory, is fine. But push it too far, and everything falls apart gloriously. And knowing in advance whether you'll hit that bound is not always obvious. If I know from the beginning something will be a big project, I start it in C++.