OR [NMF] Match sets?

[fikovnik]

Hi,

I was wondering about the match sets you are using in the solution. Each graph pattern in the case study defines a query, a repair action and a match set---i.e. a set of elements that should be returned by the query for all instances of where the given query holds.

For the PosLength and SwitchSensor you select as required a segment and a switch, however, for the others you create a different matches:

• for SwitchSet instead of a tuple of (semaphore, route, swP, sw) you select only (swP),
• for RouteSensor instead of a tuple of (⟨route, sensor, swP, sw⟩) you select only (route, sensor, swP),
• for SemaphoreNeighbour instead of a tuple of (semaphore, route1, route2, sensor1, sensor2, te1, te2) you select only (route1, route2, te1, te2)

I wonder what effect does it have on the result?

There is also a mismatch between the code and document. In the document you use different matches. Also I did not find mention anything about how the matches are used for the comparison. I somehow guess how it works bu looking at the sortKey in http://ttc2015trainbenchmarknmf.codeplex.com/SourceControl/latest#TrainBenchmarkNMF/TrainRepair.cs but it would be great to have it explicitly explained (you can save space by removing listing 1).

[szarnyasg]

Hi! @fikovnik, there is a discussion about this in issue #12 as well.

[georghinkel]

Hi,

as Gabor already provided the link, there is no such thing as pattern matches in NMF Expressions. In the paper, I wanted to demonstate the minimal code for detecting the patterns described in the task, thus also Listing 1. As a reason, I think that the requirement to store and sort the matches is a bit artificial, though I understand the necessity to have a deterministic result set.

In particular, for example in the SemaphoreNeighbour query it is absolutely not necessary to save the track elements to repair the validation error. The only model elements that are required are the routes.

Following this minimalistic approach, I have only selected the model elements required to create the match descriptions ("sortKeys").

Regarding the effect on the result, there is hardly any effect. Internally, NMF Expressions creates a collection of an anonymous type which is then mapped to the propected match element. In the future, I want to get rid of this mapping, but currently it is there, basically because the language designers of C# thought it was cheap that way (which is true unless you execute it incrementally). As a consequence, it practically doesn't make a difference how many members you put in the resulting set, from a performance point of view.

Cheers,

Georg

[fikovnik]

I guess it would be good to make a note that the code listing is only an excerpt of the solution and part is missing, just to avoid surprises :-). Regarding the necessity of the matches, I see your point, yet I think it is either good to open an issue (perhaps you did and discuss this openly) or at least again make a statement in the doc that you have decided not to follow this and that because this and that reason. I mean there are more things which could have been avoided, yet they are required because of the way the framework is set and then it makes it easy to understand the solution.