OR (NMF): return values of patterns and sortkeys

[szarnyasg]

Hi!

@develman

The patterns are a bit too simplified in the paper compared to the implementation (https://ttc2015trainbenchmarknmf.codeplex.com/SourceControl/latest#TrainBenchmarkNMF/TrainRepair.cs). Also, the implementation does not strictly adhere the case description. For example, the RouteSensor pattern is defined as

                Fix(pattern: from route in rc.Routes
                             from swP in route.Follows.OfType<SwitchPosition>()
                             where swP.Switch.Sensor != null && !route.DefinedBy.Contains(swP.Switch.Sensor)
                             select new { Route = route, Sensor = swP.Switch.Sensor, SwitchPos = swP },
                     action: match => match.Route.DefinedBy.Add(match.Sensor),
                    sortKey: match => string.Format("<route : {0}, sensor : {1}, swP : {2}, sw : {3}>",
                         match.Route.Id.GetValueOrDefault(),
                         match.Sensor.Id.GetValueOrDefault(),
                         match.SwitchPos.Id.GetValueOrDefault(),
                         match.SwitchPos.Switch.Id.GetValueOrDefault()));

There are two issues:

1. The paper omits the SwitchPos value compared to the actual implementation.
2. The implementation does not return the Switch explicitly (of course you can get it by navigating from the swP variable).

The paper also omits the sortKey but that's not really issue (and it's also explained in the text). Regarding the sortkeys, do you convert the tuples to strings? I think it will not work perfectly, for example a lexicographical sort for route 9 and 10 would result in this:

<route : 10, ...>
<route : 9, ...>

Just a sidenote: I think it would be worth discussing that you had to utilize a pseudorandom generator implemented in .NET (to produce the same results as the one in Java).

Gabor

[georghinkel]

Hi Gabor,

oh, sorry, apparently I did not keep the versions in the paper, the repository and on SHARE consistent. However, I am guessing that the repository version is probably outdated, since the most recent changes have been done on the SHARE demo already that did not have a connection to the repository. I will clarify this tomorrow.

Regarding the sort keys, yes, I converted the tuples to strings. There is no such thing as a formal notion in matches in NMF Expressions and so I did not implement this that careful. Since I do not regard this as part of solving the tasks but only part of complying to the benchmark, I did not include a description in the paper, particularly because I tried hard to adhere to the pre-proceedings page limit of 5 pages to not let the paper diverge between the versions.

However, the sorting problem can be easily fixed by replacing <route : {0}... by <route : {0:0000}... which will print the ids in four digits such that 1 is printed as 0001.

Cheers,

Georg

P.S.: You might have addressed the wrong Georg, but sorry fo the late response, anyhow.

[georghinkel]

OK, after investigating the issue on the RouteSensor pattern more closely, you are absolutely right, the implementation diverges from the case description.

However, this was absolutely intended in this particular situation since the solution paper only solves the task, but not strictly adhered to the given pattern. In particular, the SwitchPosition is not required to fix such a match and therefore it is omitted in the case description.

The reason is that I implemented all the patterns first before I understood the sorting. Afterwards, I adjusted the pattern a bit to make the requested sorting possible. That meat that the pattern had to include the switch position although it is not required. Further, the SwitchPosition cannot easily be reconstructed from the switch, one would have to search for it as there might be many.

Thus, the solution paper for brevity only shows the patterns to solve the actual problem, while the implementation rather focusses on compliance with the benchmark framework.