[Freeciv-Dev] Re: [RFC] Path finding implementation.
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Tue, Jul 30, 2002 at 05:30:16PM +0100, Gregory Berkolaiko wrote:
> On Tue, 30 Jul 2002, Raimar Falke wrote:
>
> > On Tue, Jul 30, 2002 at 01:06:34PM +0100, Gregory Berkolaiko wrote:
> > > On Mon, 29 Jul 2002, Raimar Falke wrote:
> > >
> > > > > so the name is not good, EC can be bigger than
> > > > > PF_MAX_EXTRA_COST, but it will effectively mean that we'd prefer a
> > > > > longer
> > > > > but safer route. Although I am not a big fan of this practice, I
> > > > > regocnize it might be useful.
> > > > >
> > > > > But the EC supplied to safe-path routine should not exceed
> > > > > PF_MAX_EXTRA_COST
> > > >
> > > > I don't see how this will solve the problem above.
> > >
> > > What is the problem above, maybe we are talking about different problems?
> > > Is it "to ensure that the frontier tiles will be dequeued basing on the
> > > time that it takes to reach them, i.e. a tile that is (k+1)turns away
> > > will
> > > never be considered before a tile k turns away" ?
> >
> > Yes this is the problem. Ok I try it another time: we have a position
> > and want all (micro) paths from this position which end in a safe
> > position in this turn. If they can go over safe tiles or not isn't the
> > problem here. We need the user-supplied ECOT because the path choosen
> > needs it. However this user-supplied ECOT can return such big ECOT
> > that a tile at (k+1)-turn is returned before a k-turn tile is
> > returned. It doesn't depend how you choose the ECOT and the COP
> > function. It was a design goal that you can compensate big ECOT with a
> > turn and vice versa.
>
> Don't you think that asking a user to supply ECOT not exceeding
> PF_BMC_FACTOR when also supplying is_position_dangerous call-back is
> quite reasonable?
I think it is a restriction which can be removed quite easy. The
callback are a few lines and the code which calls the callback is also
only a few lines. This is nothing compared to the
is_position_dangerous support.
> Not incorrect but suboptimal. Never mind for now. I was just confused by
> the the two calls to expand from macro_get_next_position
Feel free to optimize it.
Raimar
--
email: rf13@xxxxxxxxxxxxxxxxx
"Are you saying that you actually used the Classpath Java AWT classes in
addition to the GTK peers and got them to display something?
Wow. That's way better than I did and I wrote the code!"
-- Aaron M. Renn in the classpath mailing list
- [Freeciv-Dev] Re: [RFC] Path finding implementation., (continued)
[Freeciv-Dev] Re: [RFC] Path finding implementation., Ross W. Wetmore, 2002/07/06
[Freeciv-Dev] Re: [RFC] Path finding implementation., Gaute B Strokkenes, 2002/07/21
[Freeciv-Dev] Re: [RFC] Path finding implementation., Gregory Berkolaiko, 2002/07/30
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Raimar Falke, 2002/07/30
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Gregory Berkolaiko, 2002/07/30
- [Freeciv-Dev] Re: [RFC] Path finding implementation.,
Raimar Falke <=
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Gregory Berkolaiko, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Raimar Falke, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Gregory Berkolaiko, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Raimar Falke, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Gregory Berkolaiko, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Raimar Falke, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Gregory Berkolaiko, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Raimar Falke, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Gregory Berkolaiko, 2002/07/31
- [Freeciv-Dev] Re: [RFC] Path finding implementation., Raimar Falke, 2002/07/31
|
|