|
![](/i/fill.gif) |
clipka wrote:
> Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |