3 ms·
That's a good point. I didn't think of like that. I think the "don't allow" cases might be modelled in the heuristic but my initial graph was just all open.
by noufalibrahim 2y ago
That's a good point. I didn't think of like that. I think the "don't allow" cases might be modelled in the heuristic but my initial graph was just all open.
- dietr1ch 2y agoI'm not sure what you mean by the initial graph being just all open, but I'm still convinced that modelling things only in the heuristic is wrong. Here's why it fails eventually, Hacking only the heuristic side will seem to work as intended on short paths, but as the f-value (g+h) naturally starts being dominated by g as the solutions become longer, you'll see that the hints at what not to do embedded in the heuristic will start to seemingly become neglected by A*
- noufalibrahim 2y agoWhen I said "all open", I meant that none of the constraints were included in the graph I started with. All paths between the two endpoints are equally valid. I wanted then, to find paths that didn't overlap with other connectors, that didn't go too close to other objects and didn't turn too much. These, I modeled by adjusting the heuristics so that such paths are penalised. I see your point. The penalties right now are "big" but only when compared to the values of g at the beginning. As it moves forward, even the big penalties will be swamped by the g and hence, the heuristics will be ignored. I'm not sure about how else to model this though.