On Wed, Jul 11, 2012 at 12:36 PM, Max Harms <raeli...@gmail.com> wrote:
> A few aren't what I'm looking for though. One of the biggest is that while
> my example happened to have steps with uniform length, I'd like my A*
> program to work on arbitrary graphs, where a step from one space to another
> can have any non-negative real length. Thus it doesn't work to simply count
> the length of the path for the general case.
Can you show me some examples of what this kind of data would look like?
Or do you mean "cost is an expensive to calculate"? If so, I think
the right approach there would be to persist calculated scores. (If
you can't calculate the cost of your path, given the path, and the
system in which the path exists, that should mean that the cost does
not depend on the path?)
Note also that this particular datum was a term in computing the
score, rather than being the complete score. So, thinking about it as
distance... how hard can it be to calculate distance?
Which brings me back to thinking about caching scores. Something like this:
frontier=. frontier, newfrontier
scores=. scores, newscore
priority=. /: scores
frontier=. priority { frontier
scores=. priority { scores
> For validIn, it seems like the right half of the outermost fork ((|~ #)
> -:"1 [) is checking for within-bounds-ness of the index parameter.
> Unfortunately, I think it fails for higher-dimensional cases like index 0 3
> 0 of array of shape 2 5 2.
> Example:
> 0 3 0 ((|~ #) -:"1 [) i.2 5 2 NB. Returns 0, which is a bug
I should have been using (|~ #)"1 instead of bare (|~ #).
> Here's my newest version, with some of your changes incorporated, and some
> changes inspired by your work: http://pastebin.com/RjQA69j6
>
> Thanks!
> - Max
I will read it soon...
> P.S. If you're having trouble understanding the dynamic-cost nature of A*,
> consider the following extendPath function:
>
> gridExtendPathWithSwampsInsteadOfHoles =: 1 : 0
> oldDist =. > {. y
> path =. > {: y
> newPoses =. (1:"0 m) gridNeighbors {: path
> newPaths =. path ,"_ 1 newPoses
> newDists =. 6 + oldDist - 5*(m atIndex newPoses)
> newDists (; <)"_1 newPaths
> )
I think I see where you're going here. I think I still would want
cost estimates as a module independent of path generation.
I could be wrong, of course. But, if so, I am not seeing yet, where
I'm going wrong. Working data might help?
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
