Open chrMongeau opened 7 years ago
While an ordered factor makes some kind of intuitive sense, I'm not sure if it will always be that simple. Is there a reason that aggregateObservationFlag
can't convert its arguments to ordered factors internally and then convert back to character at the end?
Thought I might jump in while I am here ;)
The reason why the weights were numeric rather than ordered factor was because they were used to construct the distribution of each value. These distributions can then be used to balance the SUA or the FBS.
However, nobody understood how it works before I left, so I guess it is no longer relevant. The details of the methodology can be found in the vignette. But you have to compile it yourself.
Here you go, had to Google how to compile an Rnw
. This is like last century technology .....
See section 4 for the reason behind numeric values.
Here is the distribution paper.
The reason why the weights were numeric rather than ordered factor was because they were used to construct the distribution of each value.
Thank you @mkao006. In this context, it makes sense. AFAIK, no one is indeed using flags in order to do what is suggested in the framework. Anyhow, for now I'm not touching anything in the design as the bottleneck in the original problem is probably somewhere else. As soon as I get time, I'll investigate further.
I like to share here an issue in the trade module, as I think it should be addressed at
faoswsFlag
level. The issues is:https://github.com/SWS-Methodology/faoswsTrade/issues/154
As I said there, I think the aggregation should be re-worked by rethinking the flags to be ordered factors. I probably miss a lot of the functioning of
faoswsFlag
, so I don't know if it would clash with the package design/goals. Anyways, given that most of the code would break if the flags are expected to be factors, maybe there should be an option toaggregateObservationFlag()
so that when it has as input ordered factors then it's behave in a predetermined way.@sebastian-c what do you think?