Depending on how serious you were about it, you could probably get a vasectomy and simply get judged sterile and solve the problem permanently.
That doesn't solve the problem, which is male who wants to have sex with many females but is selective about who gets to actually bear his children. The vasectomy prevents the male from having any children at all.
Deception is a large part of the female reproductive strategy for most animals (humans included). I foresee problems when it becomes an option for a male strategy as well.
So guy and girl are on their third date, they're on the cusp of sex and the girl says she's not on the pill and the guy says "It's OK, I'm on the shot".
Does she believe him?
Who cares? Seriously, if she doesn't want a kid she should refuse sex unless she is on the (female) pill. Males won't be taking this pill to convince a woman to have sex with them, they'd be taking this pill to prevent the woman from getting pregnant.
IOW, they won't be lying "trust me, I'm on the pill", they'd be lying "of course I think we're ready for a baby".
Currently the ability to produce/prevent a pregnancy via deception is only available to females. A male pill would give that same ability to males (produce/prevent a pregnancy via deception).
Can you imagine what would happen if males could string along a woman with "we've been trying for a year"? When males get to lie about trying for a pregnancy?
The main issue is that any watch over $200 is expected to last 10-20+ years. A smart watch is designed to last 1-2 years.
I'm sure that's not correct - people who buy those digital casios for $50 expect them to last for 10+ years. My $30 casio is over ten years old and I haven't even had to change the battery yet (it might be charging off sunlight).
To be fair, being only 4x more dangerous at this early stage of experimental testing sounds pretty impressive.
It's only impressive if you consider the problem solvable. It's irrelevant if the problem is intractable - we were "almost there" with AI for 20+ years before they finally figured out that the problem was harder than it looks.
I see the same thing with SDC. We've had good enough sensors for 20+ years. We've had the software that was 98% of the way there for almost 20 years. I give it another few years before the penny drops and the engineers realise they are trying to solve an intractable problem.
Tesla has self-driving software under test, that mostly works with their current cars.
We've had software that mostly work since the nineties. It's still at the "mostly works, in perfect conditions" stage that it's been in for almost two decades.
It is not yet ready for the public, but that isn't because of any deficiencies in the sensors.
We've had adequate sensors for far longer than we've had software that mostly works.
Hardware isn't the problem. Software is the problem, a problem that hasn't been solved since the nineties despite the huge amounts of money thrown at it.
IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).
With exceptions: yes. I thought I read somewhere that had been done. Apparently not.
With new, that's only sort of true. The compiler provides new and delete as operators, but you'll get a link error since there's no runtime for them. You can of course few trivial functions along the lines of:
I doubt it - the standard specifies the behaviour of new,
The type of free store management you want on an AVR is almost certainly domain specific anyway.
The compiler also certainly supports placement new.
Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!)
Depends on what you mean by "awfully stupid". It's very rare that throwing from a destructor is a good idea.
It's very common to throw from a constructor. In fact, that's the only way to signal an error in the constructor.
There's also no harm in using constructors which have no error condition. There's not much problem with failing to acquire resources: all resources on such small devices are entirely statically determined.
Memory, certainly. Nothing else, though. In embedded devices memory is statically allocated, but there are multiple *other* resources which can fail. Putting the initialisation in the constructor of a class while not being able to catch exceptions mean that the caller has no way to tell if a device is ready.
For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it.
I don't see why that's a problem.
It' a problem because double-initialisation (or double de-initialisation) of attached hardware almost always results in errors. An initialisation that occurs more than once is an error. Any initialisation needs to return error or success. Lacking exceptions, you can't put anything important in a constructor or a destructor.
So, sure, you can use classes, if you restrict yourself to classes with no exceptions, which means not using anything that relies on exceptions to signal errors. So, yeah, C++ works fine in embedded if you don't use constructors, destructors, overloaded operators, object assignment, object-as-parameters in function calls... probably a few other things too.
IOW, as long as you use a *subset* of C++.
Anyway, if you want a well-reasoned example, then there's this talk from the recent C++ conference:
The guy writes a simple Pong for his Commodore 64 using C++17, and keeps rather close track of the asm code being generated. He uses classes, constructors, destructors, lambdas, templates and compile-time computation.
Very unimpressing indeed. The C64 had a ton of impressive software - a spreadsheet, first-person-view mazes, platformers... and yet using C++ he could only fit a pong clone into it? This example is a case *against* C++, not for it. FWIW, I wrote a pong clone for the C64 when I was 10, and I recall taking a single weekend to do it, using a fraction of the available ram. Why not compare the C++ pong with the existing pong binaries for the C64?
It's complete non-hosted C++, with templates, lambdas, namespaces, interitance, constexpr, r-value references, auto, and so on. The C++ standard notes that non-hosted platforms are not required to provide the standard library.
IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).
Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!), which means your composite objects will have to be written using functions to create and destroy them.
For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it. You'll run into a similar issue when you try to do polymorphism without exceptions.
So, yeah, it's a pretty significant portion of C++ that can't be used.
n 1994, the twin robot vehicles VaMP and Vita-2 of Daimler-Benz and Ernst Dickmanns of UniBwM drove more than 620 miles (1,000 km) on a Paris three-lane highway in standard heavy traffic at speeds up to 81 miles per hour (130 km/h), albeit semi-autonomously with human interventions. They demonstrated autonomous driving in free lanes, convoy driving, and lane changes with autonomous passing of other cars
...
In 1995, Carnegie Mellon University's Navlab project completed a 3,100 miles (5,000 km) cross-country journey, of which 98.2% was autonomously controlled, dubbed "No Hands Across America".[37]
...
Also in 1995, Dickmanns' re-engineered autonomous S-Class Mercedes-Benz undertook a 990 miles (1,590 km) journey from Munich in Bavaria, Germany to Copenhagen, Denmark and back, using saccadic computer vision and transputers to react in real time. The robot achieved speeds exceeding 109 miles per hour (175 km/h) on the German Autobahn, with a mean time between human interventions of 5.6 miles (9.0 km), or 95% autonomous driving. It drove in traffic, executing manoeuvres to pass other cars. Despite being a research system without emphasis on long distance reliability, it drove up to 98 miles (158 km) without human intervention.
SDC's have gotten more hype the last five years than many Apple products. This does in any way mean that there have been advances over the 158km stretch of self-driving that occurred in 1995.
"Before testing them". Not before selling them. Before *testing* them.
They want to run their tests on real roads with real people; they want to put at risk innocent bystanders who are not in the least bit remotely interested in their product.
Before putting your untested crap on the road to drive amongst uninterested third parties, they *should* be validating the shit out of the system.
Real roads and real people are not there for your personal use as guinea pigs.
This time - when someone gets killed - the code review should start the same day.
Code reviews do not help with machine-learned algorithms. The algorithm is opaque even to the developer. They should not be using machine-learning and/or neural nets to steer cars. The resulting systems cannot be reviewed for accuracy and reproducibility. They can only be tested.
Brilliant and informative post. I do have a few questions myself:
-Invalid pointers (pointers not checked for validity before being used)
How do you check a pointer for validity? You can only check for NULLness, right?
-No runtime stack monitoring to ensure it doesn't overflow
How do you check this? Most uCs don't have a valgrind (although the newer Atmels have MPEs) and I'm not sure how hard it is to add stack canaries to the compiler.
The problem discussed here is that you cannot completely remove the data for "gender", as the combination of the data for "married" and "children" is not universally distributed amongst genders.
Actually, the *effect* of that bias *can* be removed by first removing the bias against men in the judicial system. You don't need to create an exception for single mothers if the number of single mothers is roughly the same as the number of single fathers.
In short, this is only a "problem" in that it is revealing a bias in data-production system (the courts).
Tesla charges an extra $3k for the Autopilot option, which includes all the sensors and actuators needed for automation. That is no where near "double".
2. If someone else does, it's their problem. They're not asking you to be their Mommy and tell them what's good (or bad) for them, anymore than you're asking them to be your Mommy....
Wait, what? You want to silence those who mock others? Did you even read your sig?
"I do not agree with what you say, but I will defend to the death your right to say it"
Are you using that quote sarcastically? Making fun of stupid people (flat-earthers, creationists, people who want to go to Mars, etc) is a time-honoured tradition.
Done. Problem solved.
And as an extra bonus (for one group or the other), someone will get to tell someone else "See!? I Told You So!"
So a win-win situation, in general. Yeah, you lose the "I told Wilbur and I told Orville that that thing would never fly" parts which sooooo many people enjoy.
You appear to be missing the fact that throughout human history, the majority of the people who said "that will never fly" were correct. They may have laughed at the Wright brothers, but they also laughed at Bozo the clown. Just because someone says that your idea is stupid, that does not automatically make your idea any better.
The majority of ideas called stupid are, in fact, stupid. A few gems turn out to be smart, but there are so few of them that they are dwarfed by the stupid ideas out there.
In this case, you're factually wrong. The argument that one will be able to hire a car for a vacation only works when most people don't hire a car for the vacation. When everybody has a short-range car, the argument breaks down pitifully. It's a stupid argument.
Slashdot Mirror
Depending on how serious you were about it, you could probably get a vasectomy and simply get judged sterile and solve the problem permanently.
That doesn't solve the problem, which is male who wants to have sex with many females but is selective about who gets to actually bear his children. The vasectomy prevents the male from having any children at all.
Deception is a large part of the female reproductive strategy for most animals (humans included). I foresee problems when it becomes an option for a male strategy as well.
So guy and girl are on their third date, they're on the cusp of sex and the girl says she's not on the pill and the guy says "It's OK, I'm on the shot".
Does she believe him?
Who cares? Seriously, if she doesn't want a kid she should refuse sex unless she is on the (female) pill. Males won't be taking this pill to convince a woman to have sex with them, they'd be taking this pill to prevent the woman from getting pregnant.
IOW, they won't be lying "trust me, I'm on the pill", they'd be lying "of course I think we're ready for a baby".
Currently the ability to produce/prevent a pregnancy via deception is only available to females. A male pill would give that same ability to males (produce/prevent a pregnancy via deception).
Can you imagine what would happen if males could string along a woman with "we've been trying for a year"? When males get to lie about trying for a pregnancy?
Were these fully autonomous,
The Uber one wasn't fully autonomous either.
The main issue is that any watch over $200 is expected to last 10-20+ years. A smart watch is designed to last 1-2 years.
I'm sure that's not correct - people who buy those digital casios for $50 expect them to last for 10+ years. My $30 casio is over ten years old and I haven't even had to change the battery yet (it might be charging off sunlight).
To be fair, being only 4x more dangerous at this early stage of experimental testing sounds pretty impressive.
It's only impressive if you consider the problem solvable. It's irrelevant if the problem is intractable - we were "almost there" with AI for 20+ years before they finally figured out that the problem was harder than it looks.
I see the same thing with SDC. We've had good enough sensors for 20+ years. We've had the software that was 98% of the way there for almost 20 years. I give it another few years before the penny drops and the engineers realise they are trying to solve an intractable problem.
How do you react to that? The car will have more information available than you would in the same situation.
My phone currently has more information than me. Doesn't mean it can tell the difference between English and gibberish when I speak to it.
The same as a human? They use visual cues such as other vehicles?
Get ready to receive your Nobel Prize, Turing Award and Fields Medal... you've managed to create AI.
Tesla has self-driving software under test, that mostly works with their current cars.
We've had software that mostly work since the nineties. It's still at the "mostly works, in perfect conditions" stage that it's been in for almost two decades.
It is not yet ready for the public, but that isn't because of any deficiencies in the sensors.
We've had adequate sensors for far longer than we've had software that mostly works.
Hardware isn't the problem. Software is the problem, a problem that hasn't been solved since the nineties despite the huge amounts of money thrown at it.
IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).
With exceptions: yes. I thought I read somewhere that had been done. Apparently not.
With new, that's only sort of true. The compiler provides new and delete as operators, but you'll get a link error since there's no runtime for them. You can of course few trivial functions along the lines of:
void* operator new(size_t s) noexcept { return nullptr; }
which fits the letter of the standard.
I doubt it - the standard specifies the behaviour of new, The type of free store management you want on an AVR is almost certainly domain specific anyway.
The compiler also certainly supports placement new.
Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!)
Depends on what you mean by "awfully stupid". It's very rare that throwing from a destructor is a good idea.
It's very common to throw from a constructor. In fact, that's the only way to signal an error in the constructor.
There's also no harm in using constructors which have no error condition. There's not much problem with failing to acquire resources: all resources on such small devices are entirely statically determined.
Memory, certainly. Nothing else, though. In embedded devices memory is statically allocated, but there are multiple *other* resources which can fail. Putting the initialisation in the constructor of a class while not being able to catch exceptions mean that the caller has no way to tell if a device is ready.
For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it.
I don't see why that's a problem.
It' a problem because double-initialisation (or double de-initialisation) of attached hardware almost always results in errors. An initialisation that occurs more than once is an error. Any initialisation needs to return error or success. Lacking exceptions, you can't put anything important in a constructor or a destructor.
So, sure, you can use classes, if you restrict yourself to classes with no exceptions, which means not using anything that relies on exceptions to signal errors. So, yeah, C++ works fine in embedded if you don't use constructors, destructors, overloaded operators, object assignment, object-as-parameters in function calls... probably a few other things too.
IOW, as long as you use a *subset* of C++.
Anyway, if you want a well-reasoned example, then there's this talk from the recent C++ conference:
https://www.youtube.com/watch?...
The guy writes a simple Pong for his Commodore 64 using C++17, and keeps rather close track of the asm code being generated. He uses classes, constructors, destructors, lambdas, templates and compile-time computation.
Very unimpressing indeed. The C64 had a ton of impressive software - a spreadsheet, first-person-view mazes, platformers... and yet using C++ he could only fit a pong clone into it? This example is a case *against* C++, not for it. FWIW, I wrote a pong clone for the C64 when I was 10, and I recall taking a single weekend to do it, using a fraction of the available ram. Why not compare the C++ pong with the existing pong binaries for the C64?
Sorry, no. It's a *subset* of C++.
It's complete non-hosted C++, with templates, lambdas, namespaces, interitance, constexpr, r-value references, auto, and so on. The C++ standard notes that non-hosted platforms are not required to provide the standard library.
IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).
Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!), which means your composite objects will have to be written using functions to create and destroy them.
For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it. You'll run into a similar issue when you try to do polymorphism without exceptions.
So, yeah, it's a pretty significant portion of C++ that can't be used.
Also, the language used by the Arduino IDE is C++.
Sorry, no. It's a *subset* of C++.
The software was 98% there 18 years ago. That last 2% hasn't been achieved in 18 years, yet you think it will be achieved in the next five?
Please cite a source for your otherwise made up numbers.
Sure thing, from the history of self-driving cars
:
n 1994, the twin robot vehicles VaMP and Vita-2 of Daimler-Benz and Ernst Dickmanns of UniBwM drove more than 620 miles (1,000 km) on a Paris three-lane highway in standard heavy traffic at speeds up to 81 miles per hour (130 km/h), albeit semi-autonomously with human interventions. They demonstrated autonomous driving in free lanes, convoy driving, and lane changes with autonomous passing of other cars
...
In 1995, Carnegie Mellon University's Navlab project completed a 3,100 miles (5,000 km) cross-country journey, of which 98.2% was autonomously controlled, dubbed "No Hands Across America".[37]
...
Also in 1995, Dickmanns' re-engineered autonomous S-Class Mercedes-Benz undertook a 990 miles (1,590 km) journey from Munich in Bavaria, Germany to Copenhagen, Denmark and back, using saccadic computer vision and transputers to react in real time. The robot achieved speeds exceeding 109 miles per hour (175 km/h) on the German Autobahn, with a mean time between human interventions of 5.6 miles (9.0 km), or 95% autonomous driving. It drove in traffic, executing manoeuvres to pass other cars. Despite being a research system without emphasis on long distance reliability, it drove up to 98 miles (158 km) without human intervention.
SDC's have gotten more hype the last five years than many Apple products. This does in any way mean that there have been advances over the 158km stretch of self-driving that occurred in 1995.
"Before testing them". Not before selling them. Before *testing* them.
They want to run their tests on real roads with real people; they want to put at risk innocent bystanders who are not in the least bit remotely interested in their product.
Before putting your untested crap on the road to drive amongst uninterested third parties, they *should* be validating the shit out of the system.
Real roads and real people are not there for your personal use as guinea pigs.
I'm surprised they don't test in the 3rd world where fewer formally care if people die from mistakes.
Because the traffic conditions are far from perfect, and the state-of-the-art in SDC battles to handle anything but near-perfect conditions.
This time - when someone gets killed - the code review should start the same day.
Code reviews do not help with machine-learned algorithms. The algorithm is opaque even to the developer. They should not be using machine-learning and/or neural nets to steer cars. The resulting systems cannot be reviewed for accuracy and reproducibility. They can only be tested.
-Invalid pointers (pointers not checked for validity before being used)
How do you check a pointer for validity? You can only check for NULLness, right?
-No runtime stack monitoring to ensure it doesn't overflow
How do you check this? Most uCs don't have a valgrind (although the newer Atmels have MPEs) and I'm not sure how hard it is to add stack canaries to the compiler.
Yeah, my office isn't a boat in the middle of a lake so I can't take the ferry there.
And driving should be safer regardless of where it ranks in the list of transportation modes.
And you never walk either.
Once the software is ready,
The software was 98% there 18 years ago. That last 2% hasn't been achieved in 18 years, yet you think it will be achieved in the next five?
The problem discussed here is that you cannot completely remove the data for "gender", as the combination of the data for "married" and "children" is not universally distributed amongst genders.
Actually, the *effect* of that bias *can* be removed by first removing the bias against men in the judicial system. You don't need to create an exception for single mothers if the number of single mothers is roughly the same as the number of single fathers.
In short, this is only a "problem" in that it is revealing a bias in data-production system (the courts).
The evidence and testing is being done, and accident rates are lower for autonomous cars already.
No, it isn't. Stop comparing "self-driving cars that are corrected by a human" with "human-driven cars".
Few will pay double for a car for automation.
Tesla charges an extra $3k for the Autopilot option, which includes all the sensors and actuators needed for automation. That is no where near "double".
They also claim that it isn't self-driving.
Ah, but without the risk there is no reward.
Yes, and we need people to take those risks. Doesn't mean we can't mock 'em :-)
Let's try a novel approach to the problem.
1. If you don't want to go to Mars, don't.
2. If someone else does, it's their problem. They're not asking you to be their Mommy and tell them what's good (or bad) for them, anymore than you're asking them to be your Mommy....
Wait, what? You want to silence those who mock others? Did you even read your sig?
"I do not agree with what you say, but I will defend to the death your right to say it"
Are you using that quote sarcastically? Making fun of stupid people (flat-earthers, creationists, people who want to go to Mars, etc) is a time-honoured tradition.
Done. Problem solved.
And as an extra bonus (for one group or the other), someone will get to tell someone else "See!? I Told You So!"
So a win-win situation, in general. Yeah, you lose the "I told Wilbur and I told Orville that that thing would never fly" parts which sooooo many people enjoy.
You appear to be missing the fact that throughout human history, the majority of the people who said "that will never fly" were correct. They may have laughed at the Wright brothers, but they also laughed at Bozo the clown. Just because someone says that your idea is stupid, that does not automatically make your idea any better.
The majority of ideas called stupid are, in fact, stupid. A few gems turn out to be smart, but there are so few of them that they are dwarfed by the stupid ideas out there.
If they think it's viable then then already have neural damage. A little more won't make much of a difference.
It is a fallacy because in Germany, school holidays start on a different day or even month in each state, precisely for this reason.
And yet they all break for christmas within a two day period - according to the timetable.
In this case, you're factually wrong. The argument that one will be able to hire a car for a vacation only works when most people don't hire a car for the vacation. When everybody has a short-range car, the argument breaks down pitifully. It's a stupid argument.