Closed operdeck closed 9 months ago
Makes sense. I was planning on extracting all generated tables into a separate method/class anyway (with a nice excel export option), so let's include this there as well.
Update: tables are separated into separate Tables class now, so adding this is trivial
Not sure I agree with myself, let's see.
@operdeck @yusufuyanik1 - just working through some of the older issues - is this still an open one? Should we just filter out omniadaptive for these purposes by default?
No we should not filter out given the introduction of treatment action fall back in '23
We can close this issue however
Op di 7 nov. 2023 16:11 schreef Stijn Kas @.***>:
@operdeck https://github.com/operdeck @yusufuyanik1 https://github.com/yusufuyanik1 - just working through some of the older issues - is this still an open one? Should we just filter out omniadaptive for these purposes by default?
— Reply to this email directly, view it on GitHub https://github.com/pegasystems/pega-datascientist-tools/issues/76#issuecomment-1798831032, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEVTKG5KE5OO4TQFH6J4W3YDJFRBAVCNFSM6AAAAAAWBIJ44WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYHAZTCMBTGI . You are receiving this because you were mentioned.Message ID: @.***>
Wont fix, OmniAdaptiveModel is used in fall back and should not be excluded
The NBAD framework always creates an OmniAdaptiveModel even if people are not actively using this. This is okay for the most part, most charts in the Health Check consider "configuration" as a facet.
But in the lists of models not receiving positives, negatives or neither, the distinction is more important. Perhaps these lists should be per model configuration or have some other way to include/exclude OmniAdaptiveModel.