4 ms·

The problem with anticipation is that nobody except you can truly know your intent. For example, walking up to a car with my keys might just mean I want to grab

The problem with anticipation is that nobody except you can truly know your intent. For example, walking up to a car with my keys might just mean I want to grab something out of the trunk; or the car might be in a closed garage and that wouldn't be quite safe at the moment. The easiest and safest thing is usually still to let people control more of what happens because there's a lot of edge cases that might add up, or have really bad consequences for when they rarely occur.

caskance 11y ago
That's not a problem with anticipation as a concept, that's a problem with bad anticipation. Certainly it's possible to detect whether the car is in a closed garage, and it will eventually be possible to predict whether you want to grab something out of the trunk or go for a drive. Even though it often feels like you do, humans generally don't know their own intents. It's not that high of a bar for a predictive system to clear.
oliwarner 11y ago
Wouldn't be safe? I'm talking about starting an on-board computer, not the engine. Unless you're going to be repeatedly walking too and from your car all day, starting a computer needlessly isn't going to be the end of the world. Yes, it may mean doing more work but that's the trade off here for "instant on". It's either always on, you wait, or it guesses when you're going to use it and you accept there are a few false positives.
- cuu508 11y ago
  > It's either always on, you wait, or it guesses when you're going to use it and you accept there are a few false positives. Or engineers reduce startup time to a point where it feels instant. Compare e.g. startup times of DSLRs and point-n-shoot cameras. With a DSLR you switch it on and it is ready to shoot by the time your finger gets to shutter button.
  - oliwarner 11y ago
    I'm not saying it has to be an exclusive development. You can improve the other stuff too, but once relative location becomes a solved problem, it presents bevy of particularly low hanging fruit. It's also very hard to engineer a boot time down. TFA is a great example of that. Hard means expertise and time and (often) more expensive hardware. So to boil it right down with my car computer example, it's far easier and cheaper to detect the key externally and boot earlier than it is to strip a 10 second boot time down to 0.1 second. If you can also use that getting-in-the-car time to do other stuff (lookup up recent searches or upcoming appointments and suggesting navigation, setting fuel waypoints if low, getting traffic advice, etc), that's all the better.
  - jimduk 11y ago
    This is why e.g. go pro uses a hybrid approach with an embedded rtos for the camera stuff and then virtualized Linux on top of this for less critical work where you want to use a stack e.g.http streaming. 3 yrs back I worked in a team which looked at booting Linux for a camera device in < 100ms and couldn't find a solution.

caskance 11y ago

That's not a problem with anticipation as a concept, that's a problem with bad anticipation. Certainly it's possible to detect whether the car is in a closed garage, and it will eventually be possible to predict whether you want to grab something out of the trunk or go for a drive. Even though it often feels like you do, humans generally don't know their own intents. It's not that high of a bar for a predictive system to clear.

oliwarner 11y ago

Wouldn't be safe? I'm talking about starting an on-board computer, not the engine. Unless you're going to be repeatedly walking too and from your car all day, starting a computer needlessly isn't going to be the end of the world. Yes, it may mean doing more work but that's the trade off here for "instant on". It's either always on, you wait, or it guesses when you're going to use it and you accept there are a few false positives.

cuu508 11y ago
> It's either always on, you wait, or it guesses when you're going to use it and you accept there are a few false positives. Or engineers reduce startup time to a point where it feels instant. Compare e.g. startup times of DSLRs and point-n-shoot cameras. With a DSLR you switch it on and it is ready to shoot by the time your finger gets to shutter button.
- oliwarner 11y ago
  I'm not saying it has to be an exclusive development. You can improve the other stuff too, but once relative location becomes a solved problem, it presents bevy of particularly low hanging fruit. It's also very hard to engineer a boot time down. TFA is a great example of that. Hard means expertise and time and (often) more expensive hardware. So to boil it right down with my car computer example, it's far easier and cheaper to detect the key externally and boot earlier than it is to strip a 10 second boot time down to 0.1 second. If you can also use that getting-in-the-car time to do other stuff (lookup up recent searches or upcoming appointments and suggesting navigation, setting fuel waypoints if low, getting traffic advice, etc), that's all the better.
- jimduk 11y ago
  This is why e.g. go pro uses a hybrid approach with an embedded rtos for the camera stuff and then virtualized Linux on top of this for less critical work where you want to use a stack e.g.http streaming. 3 yrs back I worked in a team which looked at booting Linux for a camera device in < 100ms and couldn't find a solution.