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. 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.