-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redesign of TMs #1601
Comments
Ok, what is needed is a proper description of what a theory model is, and what are all its pieces. Currently that is
That reflects a very general notion of Theory (that basically comes from MathScheme). Overly general for our purpose. But to understand what to go to next, we really ought to understand every call to |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Overview of Architecture Data Definitions: These define actual data with concrete names, symbols and units that are used to build the instance models. Theory Models: Is a model that defines and relations between data with abstract symbols (rather than concrete symbols defined in data definitions). These relations can be intermediates and do not have to be the final outputs. General Definitions: I am not quite sure, but I believe it " collects the laws and equations" from the Theory Models Instance Models: Links the concrete symbols to the theory models to actually obtain the outputs. In other words IM = DD+TM+GD Problem: We would like our Theory Models to collect knowledge, generate some additional knoweldge, and store that additional knowledge. Question 1: What knowledge would we like the Theory models to collect?
Question 2: What knowledge would we like Theory Models to generate from the collected knowledge?
A side note: A lot of the knowledge in theory models is already stored/captured elsewhere. For example the description section is generated from the Unital chunks. Hence there is not much we could extract from descriptions then what is already found in Unitals.hs. Likewise I do not think that we should/could extract anything from the notes, as they are very specific and hence not general enough to be used elsewhere. This meant that the only knowledge that we could extract, has to come from new knowledge that was created for TM/GD/DD/IM (i.e. the relations/expr). Question 3: How would we store that knowledge? i.e. What does a code solution look like. a) First we need to decide if we are looking to classify equations into types (such as vector, differential, etc.) or models into kinds (vector model, differential model, etc.). b) We would essentially need to create a datatype, c) Make a function to derive the ``relationType d) The question is then at what point is the datatype I will first show the architecture of relations in Drasil Here are our potential options
Note that Expr and Relations are synonyms, if that confused you 😃. Here is the code for Relation Concept just for reference: data RelationConcept = RC { _conc :: ConceptChunk
, _rel :: Relation
} |
This comment has been minimized.
This comment has been minimized.
With regards to new comments in this issue and in #1174 , I am just going to jot down some new conclusions:
Now 3 solves one of our issues related to this issue, that is we should add a field to QDefinitions to indicate whether if it is a differential, vector, scalar, etc definitions. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Above (#1601 (comment)) @JacquesCarette asked for my notes on the relation between TM/GD/DD/IM. I've thought about it, and looked through my notes, and I cannot think or find anything I can point to. The specific figure relating TM/GD etc was an outcome of a problem that Yuzi was having with circular dependencies. It made sense as a model, so we tried it, and it worked in all our examples, but I don't think we have proven it. We've had plenty of discussions, and conversations are probably scattered through the issue tracker, but I can't think of a specific resource I can point to. I remember in particular that we discussed this when we discussed "theory specialization." We are currently discussing this under #2195. The TM/GD etc relation is based on experience/common sense. It would be great to try to formalize this somehow has a theory specialization. I think this ties to the challenges of redesigning the TMs. @JacquesCarette is there a good resource on theory specialization that @muhammadaliog3 and I can look at? |
This was originally 2 posts, one on the relToQd hack and other on the current state of 1601. I have however combined and summarized them. I think I need @smiths for all 4 of them.
We have 3 options Option A: We could think of a design such that the way we define equation’s should be DIFFERENT depending on what type the equation is. Number 3 and 4 have to do with the relToQd hack, and I argue that relToQD is not a hack, but rather necessary.
The big question is do we include the equal to sign or not in the qdefinitions fr Equational Models. Here are the current conventions Drasil-examples: Yes the equal to sign is included in the relation. Hence because the generated code has different needs, which is why I have concluded that the relToQd hack is needed either in the drasil-gool or drasil-docLang. For example when I removed the reltoqd hack on friday, and got things to compile (what I had to do is explained in the next question), I noticed with just pbIsSafeQD :: QDefinition
pbIsSafeQD = ec isSafePb ( sy probBr $< sy pbTol) The generated code comes correct, but the equation display in SRS is incorrect. Meanwhile if I change the qdefinition and add the equal to sign pbIsSafeQD :: QDefinition
pbIsSafeQD = ec isSafePb (sy isSafePb $= sy probBr $< sy pbTol) Then the equation displayed correctly in the SRS, but the generated code does not match stable with the following lines differing
pbIsSafeQD = fromEqn' "safetyReqPb" (nounPhraseSP "Safety Req-Pb")
EmptyS (Variable "is-safePb") Boolean (sy isSafePb $= sy probBr $< sy pbTol) Then drasil will not compile. But if were to redefine the QDefinition in terms of the previously declared quantityDict, isSafePb like the following pbIsSafeQD = ec isSafePb ( sy probBr $< sy pbTol) OR just change the UID to match the quantity it is defining like the following pbIsSafeQD = fromEqn' "isSafePb" ……….. THEN drasil would compile since it knows how to connect isSafePb to the other equations. Also note that the FIRST implementation causes differences in the label of the IMOD with the generated SRS. This occurs because the generated SRS just takes the label of isSafePb, while the stable SRS uses the label of IMODS. However this can easily be fixed with a new QDefinition constructor. |
On your two points:
[As you phrase it, I don't see a big difference between options A and B.] We want option B:
We already have ODE models. So we need to implement at least equational, ODE, and 'other'. Where it's fine to basically do nothing with the 'other' ones. The point is one of knowledge encoding, and one of form (the way an equation looks) versus function (knowing it's just a relation, versus knowing that it is a definition). Math here has its notation wrong. Some PL, have fixed that: some languages use The reason Note also that I think you need to ponder the concept of "knowledge capture", and its implications, much more deeply. Your proposed solutions are too close to 'pure code', rather than being based on a broader conceptual understanding of what we're trying to achieve with Drasil. [And we, @smiths and I, are definitely at fault for not having briefed you more deeply about that!] |
In an attempt to address these issues through knowledge capture I will split this post into 2. The first will be just "knowledge capture" and the second will be related to code.
Take a look at this example of "moment equilibrium" relation. momEqlRel :: Expr
momEqlRel = 0 $= momExpr (\ x y -> x +
(inxi baseWthX / 2 * (inxi intShrForce + inxiM1 intShrForce)) + y) Proposed Conceptually: Seperate the meanings of the "equal to" sign Proposed Code Solution: Option A: Any equal to sign in an expression should be assumed to mean equilibrium. Definitional equal to signs should be dealt with internally by drasil through the smart constructors. More concretely we should make our models be robust to both QDefinitions and RelationConcepts, where in QDefinitions the definitional equal to sign is added automatically (and define units,symbols and spaces) while the relationConcepts do not modify the expr's in any way (and do NOT define units, symbols and spaces). Option B: As @JacquesCarette mentioned we could seperate the expr's of ( Option C: Do both A and B I think option A is the most natural one.
As an example of this problem, we I will use the example that revealed this problem. Proposed conceptual solution: The identity of the expression is NOT the same as the identity of the quantity being defined in the equation. For example, taking E=mc^2, in science the identity of the equation is "Mass–energy equivalence", not "Energy". Proposed code solution: Drasil should internally convert the uid of the equation to the uid of the quantity being defined if need be, but they should be kept seperate as often as possible. |
We should, in general, not embed So we need to do something that is kind of like C: for each
However, I'm not sure about your conceptual / proposed solution. What I would much prefer to do is to first see 3-4 separate cases where things are unclear (which means 3 or 4 issues), the clarification for each case, and then see if we can extract a general pattern. Experience tells me that it's not quite so simple. I do fully agree there is a problem, and it needs solved. But also that we don't quite have a firm enough grasp of the actual problem, yet. |
Some examples of PROBLEM_1: I am not going to show equal to signs being used as assignments, as drasil-example is full of them and I do not think that they are very interesting. The following are uses of the equal signs that mean more than just assignments. Some examples of PROBLEM_2: If we define the QDefinition for the model as lrIsSafeQD :: QDefinition
lrIsSafeQD = fromEqn' "safetyReqLR" …. (sy isSafeLR $= sy lRe $> sy demand) We get errors, but if we define it using the same UID of the quantity it is defining lrIsSafeQD = fromEqn' "isSafeLR" … (sy isSafeLR $= sy lRe $> sy demand) Everything compiles If we define the QDefinition for the model as timeQD :: QDefinition
timeQD = fromEqn "timeRC" ….
sy flightDur $= 2 * sy launSpeed * sin (sy launAngle) / sy gravitationalAccelConst We get errors, but if we define it using the same UID of the quantity it is defining timeQD = fromEqn "flightduration" ….
sy flightDur $= 2 * sy launSpeed * sin (sy launAngle) / sy gravitationalAccelConst Everything compiles If we define the QDefinition for the model as landPosQD :: QDefinition
landPosQD = fromEqn "landPosQD" … landPosExpr We get errors, but if we make the uid the same as the uid of the quantity it is defining landPosQD = fromEqn "landingposition" … landPosExpr Everything compiles. If we define the QDefinition for the model as offsetQD :: QDefinition
offsetQD = fromEqn "offsetQD" … $ sy offset $= sy landPos - sy targPos If we make the uid of the the QDefinition the same as the uid of the quantity it is defining, offsetQD = fromEqn "offset" … $ sy offset $= sy landPos - sy targPos I hope that these 4 examples can make things clearer. |
Current State of Theory models:Empty fields in the theory models in drasil-example: "while the _vctx :: [TheoryModel] and _spc :: [SpaceDefn] fields are currently always initialized to be empty (by the constructors), I'm pretty sure that they're to be implemented in the future, so I'll leave them be." _ops :: [ConceptChunk] and _dfun :: [QDefinition] are always empty, and _defq :: [QDefinition] is empty (except by the relToQD hack in GlassBR)." Things we want to add to Theory Model/Instance Model/General Definition/Data Definition:Add ModelKinds Fixing Relations The initial problem was Eventually we determined... Which translated into the following plan
Which lead to the following problems and potential solutions
data ModelKinds = Vector QDefinition | Differential QDefinition | Vector Differential QDefinition ... We would end up with 2^5=32 possible options!. Potential unverified solutions: data equationType = Vector | Differential | Multiple | Equational | Complex
data ModelKinds = Model [equationTypes] [QDefinition] -- A list of QDefinition is used to incorporate multiple QDefinition For example Say we have the QDefinitions ["a=g" , "a=dv/dt" , F=ma] then the ModelKinds would be:
|
Thank you for the summary @muhammadaliog3. Very helpful! |
Yes, both summaries are excellent. |
@JacquesCarette The following two questions still remain unanswered
Once these two are answered, I still have to add the modelkinds before I can launch a PR. |
Closing in favour of #2599. If anyone feels otherwise, please feel free to re-open. |
As mentioned in bf2509d#r34032965, on branch
swhsTMs
:I think the current TM definition is quite broken. My new work-in-progress
tmEqn
passes in the same quantity multiple times, which demonstrates a design flaw. I think the definition of aTheory
should be:where
ModelKind
would hold theQDefinition
(orRelationConcept
). While the_vctx :: [TheoryModel]
and_spc :: [SpaceDefn]
fields are currently always initialized to be empty (by the constructors), I'm pretty sure that they're to be implemented in the future, so I'll leave them be. My only other uncertainty is_dfun :: [QDefinition]
- it is always an empty list when the constructors are called in the examples, and I'm not sure what its purpose is, so we might be able to remove it.Related to #1373.
UPDATE
Start reading from the last post on this issue
The text was updated successfully, but these errors were encountered: