Maxwell count is wrong on MMs page - could be an issue with > versus >=

I think there is small issue with the count of Maxwells, though if I am right it might be worth checking if it applies to MiRBs and TeraMiRBs too
I have a spreadsheet into which I post the daily stats from Free-DC for which I am very grateful thank you very much.
The issue is with the mms page. In my case it states that I have 14 Maxwells, but my spreadsheet highlights those MMs where the count exceeds the number required for a Maxwell in the Free-DC data, and it is showing 15 which if I manually check appears to be correct.
I have taken into account that you can't get a Maxwell for Maxwells (and similarly a MiRB for MiRBs and also for TeraMiRBs)
My suspicion lies with my SubTrigggl value which is exactly what is required to get a Maxwell. All the others Maxwells that I have, have more than is needed. I don't know how long this has been there but my SubTriggl count has been changing of late.
Apologies if I am being stupid, but I have checked my spreadsheet and created a new worksheet to double check, and at the end of the day the data on the mms page clearly demonstrates the problem. I think there is a > where there needs to be a >=, and it may well apply to MiRBs etc.
Cheers
Mark

Edit - Or could this be a rounding thing? With my number clearly being an integer - 5, but the number required that it is comparing it with is actually 5.2 but showing as 5?

My impression was that this table stopped being updated when the green ticks appeared and the Mawell count was removed from a user's home page stats.

Quote:

---

Originally Posted by PDW

My impression was that this table stopped being updated when the green ticks appeared and the Maxwell count was removed from a user's home page stats.

---

I am talking about the excellent and newer MMs (Test) page which lists the numbers all together (Projects and Subproject MMs) as well as the number required of each to gain a Maxwell, MiRB or TeraMiRB.
Both are being updated however and both currently show the same problem which I suspect most people will not see.

I could be wrong but I think the new page is pulling the total from the same place that the single Maxwell page is getting it from.
I have 32 ticks but only 30 on both pages, it has been wrong for quite some time, my recollection is it went wrong when the Maxwell listing was removed from the user's home page.

I'm having to go back and try to remember how these work.

Isn't it to get a maxwell you have to have >= highest score / 2 ?

So let's take the Subtriggls, the highest score is 11 and you have 5.

The issue may be that on your mm page it shows that 5 is needed for a maxwell but that's incorrect. I'll add a decimal place to that. Take a look in stats6 now ?

Yes that appears to be it. Rather than include an unnecessary decimal point though (given that you can't actually get 5.5) it would be better and more accurate to just add a half them all or round them up rather than down whichever is easier. After all you would need 6 in the subtrigggls example. It would also save me some hassle in my spreadsheets though that is beside the point. Whatever you think works best Bok. Cheers

You are probably aware of this Bok but subTeraBoks and subBoks seem to be missing from the stats 6 version of the page - just thought it worth throwing that in in case you ever copied stat6 to stats.
FWIW I just rejigged the format of a column in my spreadsheet and it doesn't matter a jot to me whether its 5.5 or 6 now - though it would be better as 6 from a realism point of view.

Quote:

---

Originally Posted by MarkRBright

You are probably aware of this Bok but subTeraBoks and subBoks seem to be missing from the stats 6 version of the page - just thought it worth throwing that in in case you ever copied stat6 to stats.
FWIW I just rejigged the format of a column in my spreadsheet and it doesn't matter a jot to me whether its 5.5 or 6 now - though it would be better as 6 from a realism point of view.

---

I changed it so it would be 6 in that case

ceil(c.total/2) as num_maxwells

I'll have a look at the other issue in a bit.

Quote:

---

Originally Posted by Bok

I'm having to go back and try to remember how these work.

Isn't it to get a maxwell you have to have >= highest score / 2 ?

So let's take the Subtriggls, the highest score is 11 and you have 5.

The issue may be that on your mm page it shows that 5 is needed for a maxwell but that's incorrect. I'll add a decimal place to that. Take a look in stats6 now ?

---

You told me last year...

My current algorithm is that you get it when score is >= floor(max/2).

so if you have 5 and the max is 11. Is 5 >= 11/2 === is 5 >=5

I am pretty sure that what PDW says is the way it used to work. I certainly used to have a Maxwell for SubTrigggls, though whoever is in the number one slot may have just gotten an additional one so I can't be sure.

I'm open to change it to that if you guys want it to work that way :)

Just let me know

I would think a majority would go for rounding down over rounding up. I know I would, as I think (and PDW seems sure) it's how it worked before and of course it would restore my Maxwell count to what it was :-)

Quote:

---

Originally Posted by PDW

You told me last year...

My current algorithm is that you get it when score is >= floor(max/2).

so if you have 5 and the max is 11. Is 5 >= 11/2 === is 5 >=5

---

Having read more, I replied to your email to say...

Okay, but I've only ever seen it described on various forums along these lines "remember you need to have at least half of the max to get the maxwell".

That is from your forum by you.

You didn't reply after to say you had changed it but it looks like you must be doing it one way to give the ticks and another way to get the Total value.
I'd like it to be consistent so ticks = total please.
Whether it is up or down is swings and roundabouts :)
I have a few swings but still lots of roundabouts :D

Quote:

---

Originally Posted by PDW

... it looks like you must be doing it one way to give the ticks and another way to get the Total value.
I'd like it to be consistent so ticks = total please.
Whether it is up or down is swings and roundabouts

---

Seconded :D

I see what you did there Bok and it looks right to me. It's always better to avoid taking things away. :thumbs:

It is probably too late for me to comment on this but I prefer "ceiling" rather than "floor." I liked the idea of 1/2, but in my way of thinking 5 is not good enough for 5.5 and thus 6 would be needed to achieve at least 1/2 of 11.

Hey Bok,
This thread may not be dead yet.
I just noticed that I get an additional Maxwell on stats6 compared to stats, and the only thing that can account for it in my numbers is the Subtriggls. In both cases it says I need five for a Maxwell, and in stats 6 I get it and stats I don't.
Basically as it stands stats6 rounds the number you need down (i.e. 5.5 -> 5) before comparison and stats rounds up (i.e. 5.5 ->6)
I am not complaining either way as before, but I thought you should know they were behaving differently. Stats is currently 'wrong' in the sense it says one thing but does another.
Just thought you should know.

fixed, it should correct overnight

Excellent.
I don't know if this is worth knowing but I have found another slightly harder to explain discrepancy between stats and stats6 on the userbycpid page.
It may be nothing, but it may indicate something you might want to look at.
On stats, my line 98 shows NanoHub@home which shows the last 4 numbers on the row (Team Rank, Project Rank, Country Rank and Join Date Ranke) as
3 180 6 3
Yet on stats 6 the same line shows
3 133 5 1

I haven't done anything with NanoHub@Home for some time - as shown by the RAC and FDC-RAC both being zero.
I confess that I really don't care about this but I thought you might be interested to see why the numbers were different when all the others appear to be the same, in case it holds some deep, dark and extremely sinister weird secret thingy. ;-)

The two references, in case it saves you a millisecond, are as follows
https://stats.free-dc.org/userbycpid...617eb6b8903f8c
https://stats6.free-dc.org/userbycpi...617eb6b8903f8c

In the meantime I have this afternoon just collected (OK I'll need to wait for iThena to release the numbers) my final SubTrigggl and it's corresponding Maxwell, 10K, Nebber (in due course ;-)) and SquarePants and barring a few bits of tidying up I am mostly going to be out of here and out of your hair, so let me take a moment to just say thank you very much again Bok for making it much more fun than just merely crunching stuff for science. This site is quite simply excellent, and your efforts have been hugely appreciated. Thank you.

interesting. You may have found a rather interesting bug and it's probably not just manifesting there.

I think it's due to the mariadb server on stats6 being in strict mode. The nanhub updates were giving an error on stats6. This (amongst many other things) actually causes errors on columns when the value is too large for it, which is not that unusual for boinc. I should just change a lot of columns to max varchars but honestly I'd rather just truncate a lot of the time which is what it will do in non strict mode.

I've set it to non strict, let's see if that corrects it.

I am glad you found it interesting.
This morning I found the two sets of numbers to be the same as they were yesterday. I'm not sure if you would have expected something to correct overnight or not, but I just wanted to let you know that I still have 2 rather different versions of NanoHub.
Perhaps more interesting though, is this morning I have on the mms page another odd discrepancy between stats and stats6. I have one more Vaio on stats6. So I have just spent a few moments tracking down the two userbycpid pages and found two things. 1) Rakesearch is also different and 2) I really need to get a life ;-)
Just FYI Rakesearch for the same last 4 digits (Team Rank, Project Rank, Country Rank and Join Date Rank) shows
on stats
7 737 60 6
on stats6
8 707 59 5

This time the different Join Date Ranks cause a difference in MMs Vaios otherwise I wouldn't have seen any difference, but at some point the difference in Rank it could easily effect Top 10's 100's etc for some people. Perhaps there is something slightly more major here.
Anyway good luck with finding whatever is causing these differences.

looks like it was causing update errors on a few projects as I've now got credits for rakesearch & odlk on stats6 today. Nanohub only just updated (it only exports once per day) and looks correct now.