Talk:Opasnet (R library)

-- Teemu R 12:20, 11 June 2012 (EEST)

How to read discussions

Fact discussion: .
Opening statement: Further developement Closing statement: Under discussion (to be changed when a conclusion is found) (A closing statement, when resolved, should be updated to the main page.)
Argumentation: Whenever a new general methodology is being developed, the single most important goal in my opinion would be to make it as practical as possible. Inpractical methodolgies never live for long. Hence to define our goal I'll try to describe my ideal practical methodology for building variables and assessments. The ovariable format has already been defined and all methods and functions should be built around that. My idea is as follows: All variable pages can have 4 components Data (in a data-table) Formula, defined in unrunnable R code (Init functions, whatever it's called) Dependencies, defined in the same code as formula Ovariable definition, in the same code as formula and dependencies It is the container for all of the above points, mainly defined on the page expilicitly because it easy and would otherwise require extra lines in fetch code. Whenever upstream variables are required, usually in variable formula or assessment code, a 'fetch' function is called, which takes the dependencies as an argument. 'Fetch' then takes the arguments and checks whether they already exist in memory and if not uses the 'include' function to get the ovariable definition from the relevant page and evaluates the 'output' slot (by using interpret(data) and/or the formula + dependencies) for it and writes the completed ovariable to the global memory. ----#: . Problem is, include cannot be put inside R code. It is part of the wiki rcode-tag. And allowing parsing and evaluating of character strings could be dangerous. --Teemu R 14:52, 11 June 2012 (EEST) (type: truth; paradigms: science: comment) ----#: . Apparently there are functions called objects.put and objects.get that could be used to divert this problem. They can be used to save and load R variables from the server. --Teemu R 15:10, 11 June 2012 (EEST) (type: truth; paradigms: science: comment) Marginals need to be taken into account somehow. When evaluating ovariables upstream mariginals could limit the amount of data received (when sources are combined or dropped). They could be somehow supplied upstream, or just defined on the page. ----#: . ComputeDependencies combines functionalities described above and more. It currently fetches, evaluates, applies standard form inputs and checks marginals. The objects.put/get functionality remains at the core of this structure. --Teemu R 16:49, 27 July 2012 (EEST) (type: truth; paradigms: science: comment) Assessments The current ideas regarding oassessments need more polish. Decisions Decisions.apply works on all variables after they've been evaluated, which often means that downstream variables need to be updated. This is not efficient. Evaluating ovariables could be left to the decisions.apply function, so that it could make changes from top to bottom of the variable hierarchy. ⇤--#: . Loses flexibility in running specific nodes and using non-standard operations at any point of the model. --Teemu R 16:49, 27 July 2012 (EEST) (type: truth; paradigms: science: attack) ←--#: . This is a very important feature as I think there will always be the kind of operations that we cannot standardize or it would just be too difficult. It's also a nice thing to have in mid-development. --Teemu R 16:49, 27 July 2012 (EEST) (type: truth; paradigms: science: defence) Or a function called CheckDecisions could be added to the ComputeDependencies chain. Latter seems like the better option. Also the format of a decision variable should be: name, options (as locations under <name> index) condition function which returns a logical vector that specifies the rows of an ovariable output to which the decision is applied effect function which applies the decisions effect on the variable If we want to retain the flexibility to use non-standard operations in decisions, they should be made separate variables. So to acquire flexibility as well as convenience, we need a DecisionTableParser function which takes a table of the previous form and creates multiple decision variables out of it. Stakeholders Need to be considered only at the assessment level, so no special requirements here. Demarginalizing Could be done in the same way as Decision variables.