Not finding the fastest trace
Bug #1795866 reported by
muniz
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| TAPAAL |
In Progress
|
Critical
|
Peter Gjøl Jensen | ||
Bug Description
The model encodes the scheduling problem from
http://
Fig 1.a. The optimal time is 28. The trace exists and can be found by replacing inf by 30 in the upper bound guard for transition "endin" from place "wfinal". If we use inf instead, the result is not the fastest trace.
Best regards,
Marco
Revision history for this message
| muniz (marmux) wrote | #1 |
| Changed in tapaal: | |
| assignee: | nobody → Peter Gjøl Jensen (peter-gjoel) |
| status: | New → In Progress |
Revision history for this message
| Jiri Srba (srba) wrote | #2 |
| Changed in tapaal: | |
| importance: | Undecided → Critical |
| tags: | removed: fastest trace |
To post a comment you must log in.
Here is a net on which the problem can be reproduced. The issues is in using the GCD optimization which causes the shortest trace to be 30 time units, but with this technique disabled the shortest trace is only 28 time units.