Open wkretschmer opened 7 years ago
I wonder why is a non-normalized Select
allowed in the first place, but I'm just getting started. I mean why doesn't Select
enforce normalization by rejecting a tuple that doesn't add up to 1, or auto-normalize upon instantiation.
This is precisely the issue! The normalization is inconsistently applied. I agree that the best way to solve this might be to move some level of normalization to Select
initialization, however my concern is that the lack of normalization might occur elsewhere in the codebase.
This normalization issue is popping up in influence diagrams as well. @apfeffer do you have any objection if I change the Select factory to always normalize the factors? I don't see how this could be a problem
GO ahead.
From: Brian Ruttenberg notifications@github.com Reply-To: p2t2/figaro reply@reply.github.com Date: Tuesday, October 17, 2017 at 4:45 PM To: p2t2/figaro figaro@noreply.github.com Cc: Avi Pfeffer apfeffer@cra.com, Mention mention@noreply.github.com Subject: Re: [p2t2/figaro] Normalization in condensed Chain factor (#715)
This normalization issue is popping up in influence diagrams as well. @apfefferhttps://github.com/apfeffer do you have any objection if I change the Select factory to always normalize the factors? I don't see how this could be a problem
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/p2t2/figaro/issues/715#issuecomment-337365263, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFJkdwY2Xak9N2HOTIq2TVc1cUqWuJPIks5stRHngaJpZM4N1yBB.
In theory, the following two elements are equivalent:
The only difference is whether or not the Select in the second argument is normalized. However, running StructuredVE on the second element returns an incorrect result for the distribution. The reason why is that the condensed Chain factor is incorrect when subproblems are not normalized. There are a two ways I could resolve this: