Opened 16 years ago
Last modified 14 years ago
#1044 closed defect (fixed)
Second identical equation should be removed (from MathCore)
Reported by: | krsta | Owned by: | krsta |
---|---|---|---|
Priority: | normal | Milestone: | Red October |
Component: | Version: | ||
Keywords: | Cc: | krsta, perost |
Description
Color2 class below should be legal but both the check reports three equations and two variables and thus it cannot build/simulate.
class Color parameter Real red=0.2; parameter Real blue=0.6; Real green; equation red + blue + green = 1; end Color; class Color2 // Should be OK! extends Color; equation red + blue + green = 1; end Color2;
Change History (3)
comment:1 Changed 15 years ago by brugard
comment:2 Changed 14 years ago by adrpo
Added it to Red October milestone with low priority and tentatively assigned it to Per.
It should be easy to fix inside Inst.instClassdef2 by using Util.listUnion here:
eqs_1 = listAppend(eqs, eqs2); // eqs2 comes from extends, eqs from current scope, use Util.listUnion initeqs_1 = listAppend(initeqs, initeqs2); // initeqs2 comes from extends, initeqs from current scope, use Util.listUnion alg_1 = listAppend(alg, alg2); // is it the same for algorithms? should identical algs be unified? initalg_1 = listAppend(initalg, initalg2); // is it the same for algorithms? should identical algs be unified?
I don't know about algorithms, is it the same as for equations when inheriting them, meaning
do a union if they are syntacticly equivalent?
Also, how about errors/warnings, if we have red + blue + grean = 1.0; in the extends
class could we warn the user that similar but not equivalent equations are present?
comment:3 Changed 14 years ago by perost
Fixed in revision 6245, see test case mofiles/IdenticalEquations. The fix uses list union as suggested only for equations.
http://intranet/trac/mathmodelica/ticket/1085