View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000568 | ascend | compiler | public | 2012-10-19 19:19 | 2013-02-21 00:49 |
| Reporter | Ksenija | ||||
| Assigned To | |||||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | SVN | ||||
| Target Version | 1.0 | Fixed in Version | |||
| Summary | 0000568: If the statements inside a compound statement (e.g. a FOR loop) depend one on another, they are not executed. | ||||
| Description | For example: FOR i IN [1..n] CREATE x[i] IS_A solver_var; z[i] ALIASES x[i]; END FOR; In this example, CheckFOR returns 0 because x[i] is not defined yet and the ALIASES statement can't be executed, so neither of the two statements is executed and x[i] stays undefined. So FOR is never executed. As Ben wrote, the problem is that our bitlist for instantiator statement execution does not handle compound statements well. | ||||
| Tags | No tags attached. | ||||
|
|
I have thought about creating a bitlist for each iteration of the loop, but for large nested loops such bitlists require much memory. I think it can be avoided by creating only two bitlists for each compound statement: one has the same meaning as the usual bitlist of the model, and the other indicates if the statement has been changed in this loop (if it is contained in the loop statement list). This idea will work only if the following assumption is true: if a statement can't be executed in one iteration of the loop, it won't be executed in others, and vice versa. I have thought about different models and it seems to me that it is always true. I have tried storing bitlists in statement structs, but I have come to a conclusion that this won't work for models containing arrays of models. So now I suppose that it is better to store the bitlists it models, not statements. |
