在C#中组合代表(Sum-Product Algorithm)

时间:2015-11-24 21:36:47

标签: c# delegates belief-propagation

我目前正在为离散变量实现置信传播。

消息是功能。我需要能够使用产品和总和将它们组合起来以产生新的功能。

我目前有一个使用委托的基本实现,但我想知道是否有更好的方法来处理它。我也担心如何使用代表进行扩展。

以下是我的实施示例:

public Func<double, double> ProductFunc(List<Func<double, double>> messages)
{
    // Construct the product of the message functions
    Func<double, double> productFunc = delegate(double x)
    {
        double productValue = 1.0;
        foreach(Func<double, double> message in messages)
        {
            productValue *= message(x);
        }
        return productValue;
    };

    return productFunc;

}

有没有更有效的方法来实现这一目标?

1 个答案:

答案 0 :(得分:1)

您实际上的代码是否符合您的要求

我问,因为规格不是很清楚。您拥有的代码捕获对List<Func<double, double>>对象的引用,并返回一个Func<double, double>委托,该委托将在调用委托时枚举列表(相反)在调用方法时使用列表。

也许这就是你想要的。它与在整个过程中使用的延迟执行一致。 LINQ。但它确实意味着调用者应该打算对列表的更改将改变返回委托的评估,或者必须非常小心不要更改列表。

如果您想要实现的目的是捕获调用时存在的数学关系,您可能更喜欢这样的方法:

public Func<double, double> ProductFunc(List<Func<double, double>> messages)
{
    Func<double, double> productFunc = x => 1.0;

    foreach (Func<double, double> message in messages)
    {
        Func<double, double> currentFunc = productFunc;

        productFunc = x => currentFunc(x) * message(x);
    }

    return productFunc;
}

在我看来,无论哪种方式都没问题。它只取决于您实际想要代码的行为。你的问题没有足够的背景让我知道。

  

我也很关心如何使用委托来扩展

它应该扩展得很好。无论如何,你已经在使用代表了。以任何一种方式编写它们都不太可能导致过度的性能问题,并且在任何情况下代码都是正确表达的。如果您遇到特定的性能问题,导致代码无法满足某些客观,可衡量的性能目标,那么您可以考虑调整代码来解决这个问题(并且可能至少会失去一些表现力)过程)。