#32: code generation service

View (Anonymous)
issuedata
Classification: Bug
Topic: Website
Importance: Medium
Status: Resolved
Assigned to:
Created by: admin
Created at: 2006-08-23
progress
Deadline:
Hours estimated:
Hours needed:
Percent done:
contact
Name:
Description:
Transcript
#4: 2006-08-30 09:48 (miller)
cellml.org has now updated to the latest CellML DOM API revision. Of course, the
error handling on the site still needs to be improved (this model cannot be
processed by the CellML DOM API, due to its use of differentials in expressions,
but that is a separate issue). It doesn't hang anymore.

#3: 2006-08-24 10:35 (miller)
status: "pending" -> "resolved"
This model is not supported by the code generation service, because it has a
diff on the wrong side of the equation. Unfortunately, I made a bad assumption
in the function which looks up operators, which made it possible to get
deadlocked in some cases (like when looking up diff in the
normal, operators table, where it isn't present). This bug is fixed in
Subversion revision 530::
  Index: CCGS/sources/Equality.cxx
  ===================================================================
  --- CCGS/sources/Equality.cxx   (revision 529)
  +++ CCGS/sources/Equality.cxx   (revision 530)
  @@ -432,7 +432,11 @@
       else if (cmp < 0)
         lower = mid + 1;
       else
  +    {
  +      if (mid == lower)
  +        break;
         upper = mid - 1;
  +    }
     }
     while (true);
     free(sn);
The lower = mid + 1 case is safe because:
Suppose for contradiction that mid = upper (which would mean that lower(new)
gets assigned to mid + 1 > upper, causing a violation of our invariants).
Then that would mean that upper = mid = floor((upper + lower)/2) which implies
upper <= (upper + lower) / 2. But we know upper != lower, because this case is
only reached if upper == lower fails, and by the invariants, lower <= upper, so
lower < upper. Therefore, upper + lower < 2 * upper, so ((upper + lower) / 2) <
(2 * upper / 2), which implies (upper + lower) / 2 < upper. But then upper <=
(upper + lower) / 2 < upper, which is a contradiction.

#2: 2006-08-23 20:52 (andre)

#1: 2006-08-23 20:50 (andre)
title: "" -> "code generation service"
description: "" -> "The attached model causes the code generation service on the website to sit there thinking for ever. Possibly caused by either an error in the model (although it works in COR) or a bug in the CCGS/API implementation. Either way I think at least on the website this type of error needs to be trapped if possible."


#32: code generation service

View (Anonymous)
issuedata
Classification: Bug
Topic: Website
Importance: Medium
Status: Resolved
Assigned to:
Created by: admin
Created at: 2006-08-23
progress
Deadline:
Hours estimated:
Hours needed:
Percent done:
contact
Name:
Description:
Transcript
#4: 2006-08-30 09:48 (miller)
cellml.org has now updated to the latest CellML DOM API revision. Of course, the
error handling on the site still needs to be improved (this model cannot be
processed by the CellML DOM API, due to its use of differentials in expressions,
but that is a separate issue). It doesn't hang anymore.

#3: 2006-08-24 10:35 (miller)
status: "pending" -> "resolved"
This model is not supported by the code generation service, because it has a
diff on the wrong side of the equation. Unfortunately, I made a bad assumption
in the function which looks up operators, which made it possible to get
deadlocked in some cases (like when looking up diff in the
normal, operators table, where it isn't present). This bug is fixed in
Subversion revision 530::
  Index: CCGS/sources/Equality.cxx
  ===================================================================
  --- CCGS/sources/Equality.cxx   (revision 529)
  +++ CCGS/sources/Equality.cxx   (revision 530)
  @@ -432,7 +432,11 @@
       else if (cmp < 0)
         lower = mid + 1;
       else
  +    {
  +      if (mid == lower)
  +        break;
         upper = mid - 1;
  +    }
     }
     while (true);
     free(sn);
The lower = mid + 1 case is safe because:
Suppose for contradiction that mid = upper (which would mean that lower(new)
gets assigned to mid + 1 > upper, causing a violation of our invariants).
Then that would mean that upper = mid = floor((upper + lower)/2) which implies
upper <= (upper + lower) / 2. But we know upper != lower, because this case is
only reached if upper == lower fails, and by the invariants, lower <= upper, so
lower < upper. Therefore, upper + lower < 2 * upper, so ((upper + lower) / 2) <
(2 * upper / 2), which implies (upper + lower) / 2 < upper. But then upper <=
(upper + lower) / 2 < upper, which is a contradiction.

#2: 2006-08-23 20:52 (andre)

#1: 2006-08-23 20:50 (andre)
title: "" -> "code generation service"
description: "" -> "The attached model causes the code generation service on the website to sit there thinking for ever. Possibly caused by either an error in the model (although it works in COR) or a bug in the CCGS/API implementation. Either way I think at least on the website this type of error needs to be trapped if possible."