- 浏览: 198104 次
文章分类
- 全部博客 (185)
- A Design Patterns (2)
- B Refactoring (0)
- C Test (2)
- D Software Engineering (0)
- E Other Tech Articles (4)
- F My Blog (0)
- G TechJie forum & QQ group (2)
- H Programmer (6)
- I 杂7杂8 (4)
- J Translations (0)
- [网站分类]1.首页原创精华.NET区(包含架构设计、设计模式)(对首页文章的要求:原创、高质量、经过认真思考并精心写作) (3)
- [网站分类]2..NET新手区(用于发表不合适发表在首页的.NET技术文章,包括小经验、小技巧) (14)
- [网站分类]3.非技术区(技术之外的文章,但不要涉及任何政治内容) (40)
- [网站分类]4.其他技术区 (9)
- [网站分类]5.企业信息化 (0)
- [网站分类]6.读书心得区(技术书籍阅读心得、书籍推荐) (8)
- [网站分类]7.提问区(.NET技术方面的提问) (6)
- [网站分类]8.技术转载区(.NET技术文章转载, 请注明原文出处) (24)
- [网站分类]9.求职招聘区(个人求职、企业招聘) (0)
- [网站分类]GIS技术 (0)
- [网站分类]SharePoint (0)
- [网站分类]博客园.NET俱乐部(俱乐部组织与活动方面的文章) (2)
- [网站分类]软件发布区(发布自己开发的代码、软件) (0)
- [网站分类]网站管理区(网站管理方面的疑问、建议、意见, 寻求管理员帮助) (0)
- [网站分类]业界新闻 (6)
最新评论
-
没有终点:
不懂 lz说的是啥 我太菜了
超简单SVN教程 -
韩悠悠:
超简单SVN教程 -
DraculaW:
orz...如果让他去写书很好奇这个作者会怎么解释vector ...
又见热书讨论《JavaScript征途》 -
gigix:
weiqingfei 写道为什么国内写书的都是烂人?
为什么高 ...
又见热书讨论《JavaScript征途》 -
weiqingfei:
为什么国内写书的都是烂人?为什么高手都不写书?
又见热书讨论《JavaScript征途》
zz From:
http://jupitermoonbeam.blogspot.com/2007/05/dont-expect-too-much.html
Don't Expect too much
A long while ago (well over two years) there was a lot of fuss made on the testdrivendevelopment Yahoo group about having only one assertion per test. Dave Astels wrote a great little article and a little more fuss was made. It was one of those things you knew made sence but sounded a lot of work. I played with one assertion per test anyway and suddenly felt my code developing more fluidly as I focused on only one thing at a time and my tests looked clearer (more behavoir orientated) and refactoring became a lot simpler too.
Then Dave Astels came along and pushed the envelope further with One Expectation per Example. This really grabbed my attention as I had been enjoying the benefits of keeping my test code clean with one assertion per test but anything with mocks in it just turned into out of control beasts (especially some of the more complex logic such as MVP). Even simple four liners such as below would end up with four expectations:
public AddOrder(OrderDto)Then everytime I needed to add new functionality I had to add more expectations and anyone who read the work (including myself after 24 hours) would struggle to make head or tale out of the monster. And if tests failed it would take a day to find which expectation went wrong. If you're not careful you end up with the TDD anti-pattern The Mockery.
{
Customer customer = session.GetCurrentCustomer();
customer.AddOrder(OrderFactory.CreateOrder(OrderDTO));
workspace.Save(customer);
}
I had read Dave Astels article several times but couldn't fathom out how it worked especially seeing it was written in Ruby with the behaviour driven RSpec. In the end I had to write it out into .NET myself before I got it.
So here is a break down of how I got Dave's One expectation per example to work for me:
One Expectation Per Example (C#)
One of the first things to note is Dave uses the builder pattern in his example. The idea is that the Address object interacts with a builder to pass it's data to rather than allowing objects to see it's state directly thus breaking encapsulation. I would like to go into this technique in more detail in another article but to deliver the point quickly think that you may create an HTML builder to display the address on the web.
Well let's start with Dave's first test:
[TestFixture]You may have noticed that I've changed a few things maily to make it look consistant with .NET design practices. Basically I've introduced a Parse method rather than the from_string method Dave uses.
public class OneExpectationPerExample
{
[Test]
public void ShouldCaptureStreetInformation()
{
Address addr = Address.Parse("ADDR1$CITY IL 60563");
Mockery mocks = new Mockery();
IBuilder builder = mocks.NewMock<IBuilder>();
Expect.Once.On(builder).SetProperty("Address1").To("ADDR1");
addr.Use(builder);
mocks.VerifyAllExpectationsHaveBeenMet();
}
}
Now we need to get this baby to compile. First we need to create the Address class like so:
public class AddressAnd the IBuilder interface:
{
public static Address Parse(string address)
{
throw new NotImplementedExpection();
}
public void Use(IBuilder builder)
{
throw new NotImplementedExpection();
}
}
public interface IBuilder {}Now it compiles but when we run it we get the following:
mock object builder does not have a setter for property Address1So we need to add the Address1 property to the IBuilder. Then we run and we get:
TestCase 'OneExpectationPerExample.ShouldCaptureStreetInformation'Let's implement some working code then:
failed: NMock2.Internal.ExpectationException : not all expected invocations were performed
Expected:
1 time: builder.Address1 = (equal to "ADDR1") [called 0 times]
public class AddressRun the tests again and they work! So let's move onto the second part of implementing the Csp. Here's the new test:
{
private readonly string address1;
private Address(string address1)
{
this.address1 = address1;
}
public static Address Parse(string address)
{
string[] splitAddress = address.Split('$');
return new Address(splitAddress[0]);
}
public void Use(IBuilder builder)
{
builder.Address1 = address1;
}
}
Now a little refactoring to get rid off our repeated code we turn it into this:
[Test]
public void ShouldCaptureCspInformation()
{
Address addr = Address.Parse("ADDR1$CITY IL 60563");
Mockery mocks = new Mockery();
IBuilder builder = mocks.NewMock<IBuilder%gt;();
Expect.Once.On(builder).SetProperty("Csp").To("CITY IL 60563");
addr.Use(builder);
mocks.VerifyAllExpectationsHaveBeenMet();
}
[TestFixture]Looking good! We run the new test and we get the usual error for having no Csp property on the IBuilder so we add that:
public class OneExpectationPerExample
{
private IBuilder builder;
private Address addr;
private Mockery mocks;
[SetUp]
public void SetUp()
{
mocks = new Mockery();
builder = mocks.NewMock<ibuilder>();
addr = Address.Parse("ADDR1$CITY IL 60563");
}
[TearDown]
public void TearDown()
{
mocks.VerifyAllExpectationsHaveBeenMet();
}
[Test]
public void ShouldCaptureStreetInformation()
{
Expect.Once.On(builder).SetProperty("Address1").To("ADDR1");
addr.Use(builder);
}
[Test]
public void ShouldCaptureCspInformation()
{
Expect.Once.On(builder).SetProperty("Csp").To("CITY IL 60563");
addr.Use(builder);
}
}
public interface IBuilderThen we run the test again and we get:
{
string Address1 { set; }
string Csp { set; }
}
TestCase 'OneExpectationPerExample.ShouldCaptureCspInformation'Oh no. This is where Dave's article falls apart for .NET.
failed: NMock2.Internal.ExpectationException : unexpected invocation of builder.Address1 = "ADDR1"
Expected:
1 time: builder.Csp = (equal to "CITY IL 60563") [called 0 times]
Basically RSpec has an option to create Quite Mocks which quitely ignore any unexpected calls. Unfortunately I know of no .NET mock libaries that have such behaviour (though I have since been reliably informed by John Donaldson on the tdd yahoo group that it is possible with the NUnit mock library) . Though there is a way out: stub the whole thing out by using Method(Is.Anything):
[Test]Just be careful to put the Stub AFTER the Expect and not before as NMock will use the Stub rather than the Expect and your test will keep failing.
public void ShouldCaptureCspInformation()
{
Expect.Once.On(builder).SetProperty("Csp").To("CITY IL 60563");
// stub it as we're not interested in any other calls.
Stub.On(builder).Method(Is.Anything);
addr.Use(builder);
}
So now we run the tests and we get:
TestCase 'OneExpectationPerExample.ShouldCaptureCspInformation'Excellent NMock is now behaving correctly we can finish implementing the code:
failed:
TearDown : System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation.
----> NMock2.Internal.ExpectationException : not all expected invocations were performed
Expected:
1 time: builder.Csp = (equal to "CITY IL 60563") [called 0 times]
public class AddressRun the test and it works! Now if we run the whole fixture we get:
{
private readonly string address1;
private readonly string csp;
private Address(string address1, string csp)
{
this.address1 = address1;
this.csp = csp;
}
public static Address Parse(string address)
{
string[] splitAddress = address.Split('$');
return new Address(splitAddress[0], splitAddress[1]);
}
public void Use(IBuilder builder)
{
builder.Address1 = address1;
builder.Csp = csp;
}
}
TestCase 'OneExpectationPerExample.ShouldCaptureStreetInformation'All we need to do do is go back and add the Stub code to the street test. That's a bit of a bummer but we could refactor our tests to do the call in the tear down like so:
failed: NMock2.Internal.ExpectationException : unexpected invocation of builder.Csp = "CITY IL 60563"
[TearDown]This approach comes across as slightly odd because the expectations are set in the test but the test is run in the tear down. I actually think this is neater in some ways as it ensures you have one test class for each set of behaviours the only off putting thing is the naming convention of the attributes.
public void UseTheBuilder()
{
Stub.On(builder).Method(Is.Anything);
addr.Use(builder);
mocks.VerifyAllExpectationsHaveBeenMet();
}
[Test]
public void ShouldCaptureStreetInformation()
{
Expect.Once.On(builder).SetProperty("Address1").To("ADDR1");
}
[Test]
public void ShouldCaptureCspInformation()
{
Expect.Once.On(builder).SetProperty("Csp").To("CITY IL 60563");
}
I won't bother continuing with the rest of Dave's article as it's just more of the same from here. The only thing I'd add is he does use one class per behaviour set (or context) so when he tests the behaviour of a string with ZIP code he uses a whole new test fixture. This can feel a little extreme in some cases as you get a bit of test class explosion but all in all it does make your life a lot easier.
I hope the translation helps all you .NET B/TDDers out there to free you from The Mockery.
Tip:
In more complex behaviours you may need to pass a value from one mock to another. In those instances you can do:
Stub.On(x).Method(Is.Anything).Will(Return.Value(y));
One Expectation per Example: A Remake of "One Assertion Per Test"
Posted by dastels on Sunday, August 27, 2006
In the fine tradition of Hollywood (who these days is remaking everything from old movies, comic books, and video games in lieu of coming up with original ideas) I am doing a remake of the very first post on my blog (which itself was a repost from my Artima.com blog from Feb 2004). The original post created quite a stir at the time, and lead to many of the ideas that have evolved my understanding of TDD and now BDD.
Once upon a time (early 2004) there was a bit of fuss on the testdrivendevelopment Yahoo group about the idea of limiting yourself to one assertion per test method, which is a guideline that others and I offer for TDD work.
An address parser was the example of a situation where it was argued that multiple assertions per test made sense. Date was formatted with one address per line, each in one of the following formats:
- ADDR1$ADDR2$CSP$COUNTRY
- ADDR1$ADDR2$CSP
- ADDR1$CSP$COUNTRY
- ADDR1$CSP
The poster went on to say:
My first inclination is/was to write a test like this (in Java but you get the idea):
a = CreateObject("Address") a.GetAddressParts("ADDR1$ADDR2$CITY IL 60563$COUNTRY") AssertEquals("ADDR1", a.Addr1) AssertEquals("ADDR2", a.Addr2) AssertEquals("CITY IL 60563", a.CityStatePostalCd) AssertEquals("Country", a.Country)They didn't see how to achieve this with one assertion per test, as there are obviously four things to test in this case. I decided that rather than simply reply, I would write some tests and code to illustrate my view on the matter, and offer a solid response.
For the original post, I chose Squeak Smalltalk and Java. In this remake I'm going to use just Ruby. In the original I said "For the sake of conciseness, I'll omit any required accessors." Well.. this time around I'm not going to use any accessors, since I am more & more of the opinion that they are quite simply an idea whose sole purpose is to undermine the very essence of Object-Oriented software. I'll also be using rSpec rather than an xUnit framework.
So, where to start? Well, it often makes sense to start with something simple to quickly and easily get some code written and working. Then it can be extended and evolved. Here the simplest case is: ADDR1$CSP
. There are two requirements in the parsing of this example: that the ADDR1
was recognized, and that the CSP
was recognized. Viewed this way, we need two examples. If we want to avoid accessors (and for this exercise, I do) we need another way to see inside the object were working with. This is an address.. let's say (for the sake of argument & this exercise) that one of the purposes of having an address is to generate address labels of some sort. We could do that with an address label maker object that would interrogate the address object for it's contents and use them. A better way is to have an address label builder that the address object gives information to. It would have methods such as street_number=, csp=, etc. This is something that we can use Mocks Objects for in our examples. So, let's start with an example for ADDR1
:
context "An address with street & csp" do specify "should capture street information" do builder = mock("builder", null_object => true) builder.should_receive(:addr1=).once.with("ADDR1") addr = Address.from_string("ADDR1$CITY IL 60563") addr.use(builder) end end
To get this to pass we need an Address class, a from_string
factory method, and a use
method.
class Address def self.from_string(address_string) Address.new end def use(a_builder) end end
This lets our spec run and fail:
An address with street & csp - should capture street information (FAILED - 1) 1) Spec::Api::MockExpectationError in 'An address with street & csp should capture street information' Mock 'builder' expected 'street=' once, but received it 0 times ./address_spec.rb:7:in `' Finished in 0.003395 seconds 1 specification, 1 failure
Now let's make that work:
class Address def self.from_string(address_string) addr1, rest = address_string.split('$') Address.new(addr1) end def initialize(addr1) @addr1 = addr1 end def use(a_builder) a_builder.addr1 = @addr1 end end
This makes the example work:
An address with street & csp - should capture street information Finished in 0.003003 seconds 1 specification, 0 failures
That's well & good. The next test is for CSP.
specify "should capture csp information" do builder = mock("builder", :null_object => true) builder.should_receive(:csp=).once.with("CITY IL 60563") addr = Address.from_string("ADDR1$CITY IL 60563") addr.use(builder) end
Resulting in:
An address with street & csp - should capture street information - should capture street information (FAILED - 1) 1) Spec::Api::MockExpectationError in 'An address with street & csp should capture street information' Mock 'builder' expected 'csp=' once, but received it 0 times ./address_spec.rb:15:in `' Finished in 0.005866 seconds 2 specifications, 1 failure
Address#from_string will need to be extended (and we need to add csp support):
class Address def self.from_string(address_string) addr1, csp, rest = address_string.split('$') Address.new(addr1, csp) end def initialize(addr1, csp) @addr1 = addr1 @csp = csp end def use(a_builder) a_builder.addr1 = @addr1 a_builder.csp = @csp end end
So. We have two tests for this one situation. Notice the duplication in the tests... the creation of builder & address. This is the context. After refactoring, we have:
require 'address' context "An address with street & csp" do setup do @builder = mock("builder", :null_object => true) @addr = Address.from_string("ADDR1$CITY IL 60563") end specify "should capture street information" do @builder.should_receive(:addr1=).once.with("ADDR1") @addr.use(@builder) end specify "should capture csp information" do @builder.should_receive(:csp=).once.with("CITY IL 60563") @addr.use(@builder) end end
So, a context that creates the Address instance from the string as well as the mock, and very simple examples that focus on each aspect of that context.
Note that we don't have any direct expectations in these examples... What's up? Well, the mock is autoverifying itself at the end of each example, and that is where our expectations are.. on @address
's interaction with the mock.
The next simplest case is the obvious choice for the next context:
context "An address with street, csp, and country" do setup do @builder = mock("builder", :null_object => true) @addr = Address.from_string("ADDR1$CITY IL 60563$COUNTRY") end end
This set of tests will include ones for addr1 and csp as before (since that behaviour is required in this new context) as well as a new test for country:
specify "should capture country information" do @builder.should_receive(:country=).once.with("COUNTRY") @addr.use(@builder) end
As before, an instance variable and such need to be added to the Address class.
This drives Address to evolve:
class Address def self.from_string(address_string) addr1, csp, country, rest = address_string.split('$') Address.new(addr1, csp, country) end def initialize(addr1, csp, country) @addr1 = addr1 @csp = csp @country = country end def use(a_builder) a_builder.addr1 = @addr1 a_builder.csp = @csp a_builder.country = @country end end
Now that we are supporting country, we can go back to the first context and add an example specifying that no country information should be provided to the builder:
specify "should not capture country information" do @builder.should_not_receive(:country=) @addr.use(@builder) end
A slight tweak to Address#use
will make this work:
def use(a_builder) a_builder.addr1 = @addr1 a_builder.csp = @csp a_builder.country = @country unless @country.nil? end
From here on, the evolution gets a bit more complex, as we add the ADDR2 option to the mix.
The final code and output is:
address_spec.rb
require 'address' context "An address with street & csp" do setup do @builder = mock("builder", :null_object => true) @addr = Address.from_string("ADDR1$CITY IL 60563") end specify "should capture street information" do @builder.should_receive(:addr1=).once.with("ADDR1") @addr.use(@builder) end specify "should capture csp information" do @builder.should_receive(:csp=).once.with("CITY IL 60563") @addr.use(@builder) end specify "should not capture country information" do @builder.should_not_receive(:country=) @addr.use(@builder) end end context "An address with street, csp, and country" do setup do @builder = mock("builder", :null_object => true) @addr = Address.from_string("ADDR1$CITY IL 60563$COUNTRY") end specify "should capture street information" do @builder.should_receive(:addr1=).once.with("ADDR1") @addr.use(@builder) end specify "should capture csp information" do @builder.should_receive(:csp=).once.with("CITY IL 60563") @addr.use(@builder) end specify "should capture country information" do @builder.should_receive(:country=).once.with("COUNTRY") @addr.use(@builder) end end
address.rb
class Address def self.from_string(address_string) addr1, csp, country, rest = address_string.split('$') Address.new(addr1, csp, country) end def initialize(addr1, csp, country) @addr1 = addr1 @csp = csp @country = country end def use(a_builder) a_builder.addr1 = @addr1 a_builder.csp = @csp a_builder.country = @country unless @country.nil? end end
spec output
An address with street & csp - should capture street information - should capture csp information - should not capture country information An address with street, csp, and country - should capture street information - should capture csp information - should capture country information Finished in 0.014 seconds 6 specifications, 0 failures
Conclusion
So we took a situation that was thought to require multiple assertions/expectations in a test/example and did it in such as way as to have only one per.
The key is that instead of using a single context with a complex (i.e. multiple expectation) example for each situation, we made each of those situations into a separate context. Now each example focuses on a very small, specific aspect of the behaviour dealt with by its context.
I'm convinced writing examples like this is a useful approach. One advantage is that the resulting examples are simpler and easier to understand. Just as important, and maybe more so, is that by adding the specification of the behavior one tiny piece at a time, you drive toward evolving the code in small, controllable, understandable steps.
It also fits better into the context centered approach that is the recommended way to organize your examples. We set up the object being worked on in setup
, and wrote examples of it's behaviour in that particular context in individual specify clauses.
As I was writing this back in early 2004, something clicked. I saw these test methods (as they are in jUnit/test::unit) as specifications of tiny facets of the required behavior. Thus, it made sense to me to be as gradual as possible about it, driving the evolution of the code in the smallest steps possible. Striving for one assertion per test is a way to do that. This epiphany was one of the main drivers in my deepening understanding of what has been called Test Driven Development (and which we are now considering an aspect of Behaviour Driven Development)
If, however, you view test methods as strictly performing verification, then I can see how it might be seen to make sense to invoke some code and then test all the postconditions. But this view is not TDD (and certainly not BDD), and doesn't buy you all of the benefits that are possible. I contend that central to TDD is this notion of working in the smallest steps possible, both for the finest-grained long-term verification, and for the most flexible design evolution. Furthermore, this is best done by striving to keep tests/examples as small, focused and simple as possible.
Aiming for one expectation each is one way to get there.
发表评论
-
Rhino Mocks To The Rescure
2006-11-23 09:17 787http://developernotes.com/archi ... -
Some high level concepts
2006-11-23 09:25 951http://structuremap.sourceforge ... -
Singletons Are Evil
2006-11-23 09:56 818http://c2.com/cgi/wiki?Singleto ... -
Best and Worst Practices for Mock Objects
2006-11-23 10:00 768http://codebetter.com/blogs/jer ... -
小函数:让你的函数变短的九个好处
2006-12-04 22:15 1126Small Methods: Nine Benefits ... -
UML序列图(zz)
2007-03-19 11:28 1266级别: 初级 Donald BellIBM 2005 年 2 ... -
重写方法不被认为是在类上声明的
2007-03-22 14:54 556当在类中指定方法时,如果有多个方法与调用兼容(例如,存在两 ... -
One Assertion Per Test(zz)
2007-05-18 10:15 2177zz from :http://www.artima.co ... -
One Expectation Per Test(zz)
2007-05-18 10:18 810zz From: http://jupitermoonbeam ... -
Supervising Controller - Martin's "GUI Architectures" series (2)
2007-05-31 12:16 841zz from www.martinfowler.com To ... -
Presentation Model - Martin's "GUI Architectures" series (3)
2007-05-31 12:18 884zz from www.martinfowler.com To ... -
Passive View - Martin's "GUI Architectures" series (4)
2007-05-31 12:19 815zz from www.martinfowler.com To ... -
Rhino Mocks To The Rescure
2006-11-23 09:17 905http://developernotes.com/archi ... -
Some high level concepts
2006-11-23 09:25 882http://structuremap.sourceforge ... -
Singletons Are Evil
2006-11-23 09:56 698http://c2.com/cgi/wiki?Singleto ... -
Best and Worst Practices for Mock Objects
2006-11-23 10:00 599http://codebetter.com/blogs/jer ... -
小函数:让你的函数变短的九个好处
2006-12-04 22:15 803Small Methods: Nine Benefits ... -
UML序列图(zz)
2007-03-19 11:28 1627级别: 初级 Donald BellIBM 2005 年 2 ... -
重写方法不被认为是在类上声明的
2007-03-22 14:54 788当在类中指定方法时,如果有多个方法与调用兼容(例如,存在两 ... -
One Assertion Per Test(zz)
2007-05-18 10:15 793zz from :http://www.artima.co ...
相关推荐
CFA三级2020框架图capital market expectation内容,复习用,可以以此为基础补充自己的错题,快快下载
### Expectation-Maximization (EM)算法中文解释 #### EM算法概述 Expectation-Maximization (EM) 算法是一种广泛应用于统计学和机器学习领域的重要算法,尤其是在处理含有隐含变量(latent variables)的模型时...
关于 AI 的一些算法 !! Expectation-maximization algorithm
期待 Expectation是单元测试的断言库。 这个库的灵感来自 bdd 测试框架的 。 不再维护此包。 请改用 。 运行单元测试 composer test 代码指标 composer metrics
EM算法,全称为期望最大化(Expectation Maximization),是一种在概率模型中寻找参数最大似然估计的迭代方法。它在处理含有隐藏变量的概率模型时,能够有效地求解参数。EM算法的基本思想是通过交替进行E步骤(期望...
1.领域:matlab,Expectation-Maximization算法,EM算法的数据分类 2.内容:基于Expectation-Maximization算法(EM算法)的数据分类仿真,对比真实分类和EM算法分类+代码操作视频 3.用处:用于Expectation-...
2. **期望(Expectation)**:在测试开始前,可以设置模拟对象的期望行为,例如调用某个方法的具体参数和次数。 3. **记录与回放(Record and Replay)**:模拟对象的行为可以在测试的不同阶段进行记录和回放,确保...
4. **训练过程**:通过最大似然估计或EM(Expectation-Maximization)算法来估计模型参数。EM算法包括E(期望)步骤和M(最大化)步骤,不断迭代优化模型参数。 5. **期望步骤(E-step)**:计算每个数据点属于每个...
1.领域:matlab,Expectation-Maximization(EM)算法 2.内容:Expectation-Maximization(EM)算法数据聚类matlab仿真,动态显示EM过程+代码仿真操作视频 3.用处:用于(EM)算法数据聚类算法编程学习 4.指向人群:本...
EM算法Expectation_Maximization的python实现及其推广。可以用jupyter打开,也可用文本编辑器打开
期望规划(Expectation Programming,简称EP)是一种基于概率编程理念的新型框架,它专注于自动计算期望值。在传统的概率编程中,我们通过定义一个非规范化密度函数γ(x)来表述程序,然后通过推断引擎来近似由规范化...
期望最大化(Expectation-Maximization, EM)算法是一种在概率模型中寻找参数最大似然估计的迭代方法,常用于处理含有未观察数据(隐藏变量)的概率模型。在统计学和机器学习领域,EM算法有着广泛的应用,如混合高斯...
The code assumes that there is one observation per column. The CMVN should be applied after dropping the low SNR frames. The logical switch varnorm (false | true) is used to instruct the code to ...
2.内容:基于Expectation-Maximization算法(EM算法)的数据聚类matlab仿真 +代码操作视频 3.用处:用于EM算法数据聚类编程学习 4.指向人群:本硕博等教研学习使用 5.运行注意事项: 使用matlab2021a或者更高版本...
In this paper, a novel image fusion method based on the expectation maximization (EM) algorithm and steerable pyramid is proposed. The registered images are first decomposed by using steerable pyramid...
标题中的"GIZA++运行报告zz"指的是一个关于GIZA++工具的使用或分析的文档,这通常涉及机器学习领域中的词对齐或统计机器翻译技术。GIZA++是一个开源工具,用于在双语语料库中计算词汇对齐,这是构建统计机器翻译系统...
这是由美联储经济数据库(FRED)托管的圣路易斯...5-year-5-year-forward-inflation-expectation-rate_metadata.json 5-year-5-year-forward-inflation-expectation-rate_metadata_1.json T5YIFR.csv T5YIFRM.csv
在计算机科学与机器学习领域,聚类是分析数据的重要方法之一。它通过把数据点分成多个集群,使得集群内的数据点相似度高,而集群间的数据点相似度低。聚类算法中,k-means算法因其高效性被广泛使用。...
二、数学期望(Expectation) 1. 定义:数学期望E(X)是随机变量X所有可能值乘以其对应的概率的总和,即E(X) = ∑xi*P(X = xi)。对于离散随机变量,它是每个值乘以相应概率的加权平均;对于连续随机变量,它是函数值...
Expectation-Maximization(EM)算法是一种在统计学和机器学习中用于估计参数的迭代方法,特别适用于处理含有隐变量的概率模型。在本案例中,我们将深入探讨EM算法在数据聚类中的应用以及如何使用MATLAB进行仿真。 ...