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

Add SGIO::progress unit tests and enhance SGIO::progress #3705

Merged
merged 1 commit into from Mar 23, 2017

Conversation

geektoni
Copy link
Contributor

Unit tests for #3694 plus little changes to SGIO::progress to make unit tests pass.

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.

I like having unit tested progress bars :)

Some minor things required, then good to merge

@@ -165,7 +165,16 @@ void SGIO::progress(
float64_t v=-1, estimate=0, total_estimate=0 ;

if (max_val-min_val>0.0)
{
Copy link
Member

Choose a reason for hiding this comment

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

we usually dont do extra {} for single lines

}
else
{
/* Wrong range, exit */
Copy link
Member

Choose a reason for hiding this comment

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

superflous comment

@@ -189,6 +196,7 @@ void SGIO::progress(
if (current_val >= max_val-1)
{
v = 100;
last_progress=v-1e-6;
Copy link
Member

Choose a reason for hiding this comment

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

if you do that, why not initialise it with 0 above rather than -1?

Copy link
Contributor Author

@geektoni geektoni Mar 16, 2017

Choose a reason for hiding this comment

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

Are you referring to last_progress or v? If you're referring to last_progress I think of -1 as a value that means not initialized and I used it since there are cases in which last_progress is not set (for example when max_val-min_val<=0). Obviously, this is completely subjective. Using 0 instead of -1 should not make any difference. :)

Copy link
Member

Choose a reason for hiding this comment

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

Yeah it doesnt, just a tiny bit cleaner....your call

Copy link
Contributor Author

@geektoni geektoni Mar 16, 2017

Choose a reason for hiding this comment

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

Core developer's will is law ;). Jokes aside, I will change it to 0. As I said, it is the same 👍

Copy link
Member

Choose a reason for hiding this comment

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

Hehe ;)
We gotta make everything as good as we possibly can -- chances that somebody touches code again are pretty low, so better get it correct (and neat) in the first place.

Hey are you in IRC at some point, I remember you asked about dependencies ....

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I am still curious about them ;). Regarding IRC, I could be online tomorrow morning, will I find you @karlnapf?

@@ -288,6 +288,13 @@ class SGIO
return location_info;
}

/** get last progress
Copy link
Member

Choose a reason for hiding this comment

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

@return last time progress was registered

I.e. needs doxygen and a human understandable description (this is API doc)


TEST(SGIOTest, progress_correct_bounds)
{
/* Positive values */
Copy link
Member

Choose a reason for hiding this comment

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

pls split positive and negative into separate tests. tests should be as small as possible

EXPECT_EQ(tmp2.get_last_progress(), (float64_t)-1);

/* Negative values */
SGIO tmp;
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, split

@geektoni geektoni force-pushed the patch-13 branch 2 times, most recently from bebcb3d to b451da9 Compare March 16, 2017 13:31
@@ -288,6 +288,15 @@ class SGIO
return location_info;
}

/** get last_progress
Copy link
Member

Choose a reason for hiding this comment

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

Sorry for being picky, but these things are never fixed otherwise.
You can just remove the text here, and only have the @ in a single line

@@ -288,6 +288,12 @@ class SGIO
return location_info;
}

/** @return last progress as percentage */
Copy link
Member

Choose a reason for hiding this comment

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

A* :)

@karlnapf
Copy link
Member

Ill merge once CI is green

{
SGIO tmp;
tmp.enable_progress();
for (int i=0; i<100; i++) {
Copy link
Member

@karlnapf karlnapf Mar 17, 2017

Choose a reason for hiding this comment

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

minor, new line for {

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.

Sorry there is some things wrong with the tests that need fix. Didnt see that earlier

{
SGIO tmp2;
tmp2.enable_progress();
for (int i=-100; i>0; i++) {
Copy link
Member

Choose a reason for hiding this comment

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

this loop is never executed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

argh noob fail

SGIO tmp2;
tmp2.enable_progress();
tmp2.progress(0, 100, 1);
EXPECT_EQ(tmp2.get_last_progress(), (float64_t)0);
Copy link
Member

Choose a reason for hiding this comment

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

(float64_t)0 can be just 0.0 But in fact that is not even necessary.
What you want to use here is EXPECT_NEAR which compares floating point numbers, where you can set the epsilon to machine precision or so

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can I use EXPECT_FLOAT_EQ? Seems to have the same behaviour as EXPECT_NEAR and also its meaning is more straightforward.

Copy link
Member

Choose a reason for hiding this comment

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

Sure! Didn't know about that guy actually

SGIO tmp;
tmp.enable_progress();
tmp.progress(0, -1, -2);
EXPECT_EQ(tmp.get_last_progress(), (float64_t)0);
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, sorry I didnt spot those earler.
Cannot check floats for equality....it is not portable

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same question as above

Copy link
Member

Choose a reason for hiding this comment

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

Yep!!

Add a getter to retrieve the last_progress (for testing purpose).
@karlnapf
Copy link
Member

karlnapf commented Mar 17, 2017 via email

@geektoni
Copy link
Contributor Author

@karlnapf any update on this one?

@karlnapf
Copy link
Member

Nice patch, thanks!

@karlnapf
Copy link
Member

@vigsterkr @lisitsyn pls merge

@vigsterkr vigsterkr merged commit 17d36a6 into shogun-toolbox:develop Mar 23, 2017
karasikov pushed a commit to karasikov/shogun that referenced this pull request Apr 15, 2017
Add SGIO::progress unit tests and enhance SGIO::progress
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

3 participants