clipka wrote:
> Invisible <voi### [at] devnull> wrote:
>>> This approach often may *not* give you the optimal route. However, given that it
>>> will only very rarely be significantly worse than the optimal one, it is
>>> definitely good enough.
>> Depends on your definition of "optimal". (E.g., total distance, verses
>> estimated travel time, any tolls that have to be paid for certain
>> routes, traffic volume, etc.)
> 
> Well, it actually depends on *your* definition of "optimal": You as the user
> assign a certain abstract "cost" to any of these parameters.

That's kind of my point, yes. :-)

> So from this perspective, the "optimum" is always well-defined: Lowest abstract
> "cost". But even to these standards, the algorithm will only very seldom pick
> the optimal route - because it would by any means not be efficient to do so.
> After all, it doesn't make much sense to have your navigator spend 3 days
> finding the optimal route, if within 30 seconds it can come up with one that is
> at most 5 minutes longer :P

Indeed. And if I make a wrong turn somewhere, it would be far more 
"optimal" for the device to quickly find a new route before I become 
*hopelessly* lost in a one-way system or something.

I'm looking at you, NAVMAN! >:-[

Post a reply to this message