> First, we'll collect the cases that demonstrate a unique situation we > care about. I have 4 very specific case that show current > shortcomings.. Not just with the Ranger, but a couple we don't handle > with VRP today. .. I'll eventually get those put onto the wiki so the > list can be updated.
I'm not specifically worried here, there is already a couple of testcases in the testsuite that require symbolic information to be properly optimized. > I think most of these cases that care about symbolics are not so much > range related, but rather an algorithmic layer on top. Any follow on > optimization to either enhance or replace vrp or anything similar will > simply use the ranger as a client. If it turns out there are cases > where we *have* to remember the end point of a range as a symbolic, then > the algorithm to track that symbolic along with the range, and request a > re-evaluation of the range when the value of that symbolic is changes. > > [...] > > Does that help? If it does, I'll add this to the coverage in the wiki > page. Yes, thanks for the detailed explanation. This approach of setting aside the handling of symbolic information might end up being a good compromise between the necessary minimal[*] handling of this information and the complexity of doing it directly in the Ranger. [*] The implicit assumption hee is that a VRP implementation with full-blown support of symbolic ranges is not worth the hassle in practice. -- Eric Botcazou
