Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AnyParameterProperties tests #4421

Merged
merged 10 commits into from Dec 12, 2018

Conversation

gf712
Copy link
Member

@gf712 gf712 commented Nov 22, 2018

Added tests to check binary logic of AnyParameterProperties.m_attribute_mask.

return static_cast<bool>(m_attribute_mask & other_params);
}

bool equals(ParameterProperties other_params) const
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am not sure about this. equals should always just be true if really everything is semantically equal. So that would include the description and the name. Maybe a rename?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK! I just think in most cases the description will differ, yet we only want to know if they have the same ParameterProperties.

Could just have:

/** Compare masks */
bool compare_mask(ParameterProperties other_params) const
{
	return m_attribute_mask == other_params ;
}

and then:

/** Compare AnyParameterProperties properties */
bool equals(AnyParameterProperties other) const
{
	return (description == other.description) && has_mask(other.get_mask());
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

first one is definitely useful, so let's have that
Second one I dont know whether we need this? But if we do, then all fields need to be compared of course.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the second one is a bit of overkill and I cant think of a situation where it would be useful.. I'll just stick to the first one!

AnyParameterProperties params = AnyParameterProperties();

EXPECT_TRUE(params.equals(ParameterProperties()));
EXPECT_FALSE(params.has_property(ParameterProperties::MODEL));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as said before, can we not explicitly test that those are not set, but in fact that none are set. Otherwise we will have to modify tests when we add new attributes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did think I saw that comment in the previous PR, but the next day the comment disappeared..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that happens on force push. I keep the notification emails to not loose comments when github hides them.

EXPECT_TRUE(params.has_property(ParameterProperties::GRADIENT));
EXPECT_TRUE(params.equals(
ParameterProperties::MODEL | ParameterProperties::GRADIENT));
EXPECT_FALSE(params.equals(ParameterProperties::MODEL));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

everything else should be false. And that should be tested. Not just these two, same reasoning as above

EXPECT_TRUE(params.has_property(ParameterProperties::GRADIENT));
EXPECT_TRUE(params.equals(
ParameterProperties::MODEL | ParameterProperties::GRADIENT));
EXPECT_FALSE(params.has_property(ParameterProperties::HYPER));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these last 3 as well

EXPECT_TRUE(params.has_property(ParameterProperties::GRADIENT));
EXPECT_TRUE(params.equals(
ParameterProperties::MODEL | ParameterProperties::GRADIENT));
EXPECT_FALSE(params.equals(ParameterProperties::MODEL));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor indentation glitch

@@ -106,5 +108,11 @@ namespace shogun {
static_cast<underlying>(lhs) ^ static_cast<underlying>(rhs));
return lhs;
}
template<typename E>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++

Copy link
Member

@karlnapf karlnapf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a few minor things.

@gf712
Copy link
Member Author

gf712 commented Nov 30, 2018

Is this what you mean with check that none are set?

EXPECT_TRUE(params.has_property(ParameterProperties::GRADIENT));
EXPECT_TRUE(params.equals(
ParameterProperties::MODEL | ParameterProperties::GRADIENT));
EXPECT_FALSE(params.compare_mask(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, this just checks that one is not set.
you want to check that none are set. So you need to create an "empty" mask (all zeros) and then call compare_mask

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but this empty mask should be created via not explicitly listing the available types.
Again, this is to avoid having to touch all these tests in the case when a type is added

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK! And the EXPECT_FALSE after, are they not necessary then? They should be covered by the empty mask.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure what you mean, but what about something like
EXPECT_TRUE(params.compare_mask(ParameterProperties::EMPTY)) or similar

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But EXPECT_TRUE(params.compare_mask(ParameterProperties::EMPTY)) is the same as EXPECT_TRUE(params.compare_mask(ParameterProperties())). I can add a EMPTY though to the enum.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can, and of course it is the same. But then it wouldnt test that the default properties are indeed empty, so the test would not be of an use: It would just test that if you create two properties with the default ctor, they have the same parameters. If you would check for EMPTY (or maybe we call it NONE (and define it to be 0x0), then you also assert that the default ctor generates empty parameters, which is exactly what we want here. If people then later start messing around with the ctor (e.g. change the default), the test will fail, so it provides some protection against devs going wild

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok! But then in that case it might make more sense to instantiate the m_attribute_mask class member in the constructors with ParameterProperties::EMPTY rather than ParameterProperties() no? I just used ParameterProperties() because it was the easiest way to represent zero without any casting.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes that is even more explicit

This is the equivalent of zero
EXPECT_FALSE(params.get_model());

EXPECT_TRUE(params.compare_mask(ParameterProperties::NONE));
EXPECT_FALSE(params.has_property(ParameterProperties::HYPER));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the last three are nop now

@gf712
Copy link
Member Author

gf712 commented Dec 12, 2018

Do you think this is ready to be merged? Started working on the new getters in CSGObject using the enums as filters, and was wondering what new methods from this PR I could use.

@karlnapf karlnapf merged commit c6557e6 into shogun-toolbox:develop Dec 12, 2018
@karlnapf
Copy link
Member

As usual, let's keep an eye on azure and buildbot

@karlnapf
Copy link
Member

Thanks!

@gf712 gf712 deleted the gf712/anyparameters_tests branch December 13, 2018 15:05
vigsterkr pushed a commit to vigsterkr/shogun that referenced this pull request Mar 9, 2019
* added method to check mask
* avoids using several getters
* added tests for AnyParameterProperties
* added equals method
* overloaded `==` enum bitmask operator
* Added None enum type to ParameterProperties
vigsterkr pushed a commit to vigsterkr/shogun that referenced this pull request Mar 14, 2019
* added method to check mask
* avoids using several getters
* added tests for AnyParameterProperties
* added equals method
* overloaded `==` enum bitmask operator
* Added None enum type to ParameterProperties
vigsterkr pushed a commit to vigsterkr/shogun that referenced this pull request Mar 14, 2019
* added method to check mask
* avoids using several getters
* added tests for AnyParameterProperties
* added equals method
* overloaded `==` enum bitmask operator
* Added None enum type to ParameterProperties
ktiefe pushed a commit to ktiefe/shogun that referenced this pull request Jul 30, 2019
* added method to check mask
* avoids using several getters
* added tests for AnyParameterProperties
* added equals method
* overloaded `==` enum bitmask operator
* Added None enum type to ParameterProperties
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants