Talk:Numeric error propagation: Difference between revisions
(→What about correlations?: ignoring is ok for simple cases) |
(→Not sure how to do this: new section) |
||
| Line 6: | Line 6: | ||
:I don't want to further expand the task description with talk of correlations unless their omission really offends those in the know. (University was a few decades ago for me and I haven't made much use of the subject since). --[[User:Paddy3118|Paddy3118]] 03:13, 30 July 2011 (UTC) |
:I don't want to further expand the task description with talk of correlations unless their omission really offends those in the know. (University was a few decades ago for me and I haven't made much use of the subject since). --[[User:Paddy3118|Paddy3118]] 03:13, 30 July 2011 (UTC) |
||
::As long as the task doesn't require operations between correlated errors it doesn't make a difference. Otherwise each uncertainty would have to keep track of the error sources, which will become complicated real fast. --[[User:Ledrug|Ledrug]] 03:22, 30 July 2011 (UTC) |
::As long as the task doesn't require operations between correlated errors it doesn't make a difference. Otherwise each uncertainty would have to keep track of the error sources, which will become complicated real fast. --[[User:Ledrug|Ledrug]] 03:22, 30 July 2011 (UTC) |
||
== Not sure how to do this == |
|||
Conceptually speaking: the new type is a number plus a function of a random variable. |
|||
But consider, for example: a*a. Here, both factors depend on the same random variable. We could express this particular example as a^2, because the same random variable is being used on both sides of the equation, but in the general case? |
|||
I am not seeing how to make this consistent, except by pushing this burden of analysis onto the programmer. But that approach seems at odds with implementing this as a type. --[[User:Rdm|Rdm]] 15:55, 31 July 2011 (UTC) |
|||
Revision as of 15:55, 31 July 2011
Task updates
Unfortunately I probably won't be able to track comments on this draft task for a couple of days as I will be making the most of a weekend with my beautiful partner without our kids. For what it's worth, I had hoped to make this task rather like Quaternion type. (Maybe I should change the name to "Error propagation type")? --Paddy3118 02:59, 30 July 2011 (UTC)
What about correlations?
Even if error of a and b are fully independent, stuff like (a+b) and (a-b) would be (anti)correlated. What to do with those? Ignore? --Ledrug 03:00, 30 July 2011 (UTC)
- I purposefully skipped the stats and just extracted some equations; hopefully enough to make an interesting task. I think it might be best to leave such extensions to the individual language implementors and have them make notes in their language entry?
- I don't want to further expand the task description with talk of correlations unless their omission really offends those in the know. (University was a few decades ago for me and I haven't made much use of the subject since). --Paddy3118 03:13, 30 July 2011 (UTC)
- As long as the task doesn't require operations between correlated errors it doesn't make a difference. Otherwise each uncertainty would have to keep track of the error sources, which will become complicated real fast. --Ledrug 03:22, 30 July 2011 (UTC)
Not sure how to do this
Conceptually speaking: the new type is a number plus a function of a random variable.
But consider, for example: a*a. Here, both factors depend on the same random variable. We could express this particular example as a^2, because the same random variable is being used on both sides of the equation, but in the general case?
I am not seeing how to make this consistent, except by pushing this burden of analysis onto the programmer. But that approach seems at odds with implementing this as a type. --Rdm 15:55, 31 July 2011 (UTC)