The reporting of "Credit" for invalids - what does "--" mean ?

Sometimes we see 0.00 other invalids we see "---"

For example

invalids on this host

I think the result database always stores a numeric value for $result->granted_credit.

For web display purposes, zero credit is (sometimes) converted to "---" by the function 'result_granted_credit_string' at line 92 of

https://github.com/BOINC/boinc/blob/master/html/inc/result.inc

There's no conversion from 0 to "---" in the section

        switch ($result->validate_state) {
        case VALIDATE_STATE_INIT:
        case VALIDATE_STATE_INCONCLUSIVE:
            return tra("pending");
        }
        return $string_to_show;

which means that the cases

define('VALIDATE_STATE_INVALID',     2);
define('VALIDATE_STATE_NO_CHECK',    3);

aren't converted.

The separate case of

define('RESULT_OUTCOME_VALIDATE_ERROR',   6);

not being outcome 'SUCCESS', gets converted by the default handler at line 105.

Or something like that. Unfortunately, I don't currently have any invalid results at any other project to compare their handling of the problem.

I think the result database always stores a numeric value for $result->granted_credit.

For web display purposes, zero credit is (sometimes) converted to "---" by the function 'result_granted_credit_string' at line 92 of

Thanks Richard, i'll read a bit more tomorrow, but i should have asked better.
(I'm assuming all invalids are equal which may not be true...)

Is a task being invalid always 0.00 credit, or could some credit be given (at some later point)?

If so, then if no credit is going to be granted, should the page display 0.00?

If the jury is out (on credit to be awarded), then "---" is a reasonable display.

Or something like that. Unfortunately, I don't currently have any invalid results at any other project to compare their handling of the problem.

Milky way has the same "feature" with this host

In theory, "---" is just a clearer way of representing the value 0.00 (as slipped briefly, but was corrected, in recent alpha builds of the BOINC Manager time displays).

If the credit currently awarded, for whatever reason, is zero, the display should be "---". That should be consistent, but a couple of cases were missed.

If the credit changes in the future - it changes. Even if the project admins assign credit manually out of the goodness of their hearts.

In theory, "---" is just a clearer way of representing the value 0.00 (as slipped briefly, but was corrected, in recent alpha builds of the BOINC Manager time displays).

If the credit currently awarded, for whatever reason, is zero, the display should be "---". That should be consistent, but a couple of cases were missed.

OK got it now, thank you. We are representing null values and zero credit values the same string, i had that around the wrong way. Poor zero, it always gets picked on! **1

The other null value seen is when status is "Completed, validation inconclusive" or "Completed, waiting for validation" where it changes from "---" to "pending".

Whilst i find that "pending" clear, it's not probably not consistent.

If the credit changes in the future - it changes. Even if the project admins assign credit manually out of the goodness of their hearts.

LOL - it's the festive season admins... i'm looking under the tree...

**1 Aristotle didn't rate zero as a number either

LOL - it's the festive season admins... i'm looking under the tree...

Trouble with the Einstein back-end is its age. While they may have updated the database a little to cover for glaring mistakes, the back-end code filling out the values on the website hasn't been updated since June 2010.

So even if you'd be able to get the code to change to show all the same values everywhere, doesn't mean it'll come to Einstein. You may also have to wonder if it's something fixed in the Drupal front-end that Einstein wants to transition to.

---

What about adding the missing case like this:

    switch($result->outcome) {
    case RESULT_OUTCOME_SUCCESS:
        switch ($result->validate_state) {
        case VALIDATE_STATE_INIT:
        case VALIDATE_STATE_INCONCLUSIVE:
            return tra("pending");
        }
        return $string_to_show;
/// begin
    case RESULT_OUTCOME_VALIDATE_ERROR:
        return $string_to_show;
// end
    default:
        if ($result->granted_credit > 0) {
            return $string_to_show;
        }
        return "---";
    }

That would be plain and simple. My interpretation of "---" was always "not applicable" or "we can't decide yet" not 0.00.

My interpretation of "---" was always "not applicable" or "we can't decide yet" not 0.00.

But it's not consequent. When looking at the details of tasks that show with '---' credit in the task list, they show 0.00 credit in the details.

---

Trouble with the Einstein back-end is its age. While they may have updated the database a little to cover for glaring mistakes, the back-end code filling out the values on the website hasn't been updated since June 2010.

Actually, the server code - certainly the web server code, which is what we're talking about here - has been fully updated within the last month. That's how I was able to relate the report to current Github code, and why the same thing happens at MilkyWay. It's also probably why the issue has only just been noticed at Einstein.

Personally, I think I'd prefer to see the "---" symbol for all 'no credit' outcomes - it stands out more clearly from 0.01 or 0.09 validations. But that may just be the result of long habituation. It certainly looked odd recently to see (in my localisation) a solid wodge of 8-character times in BOINC Manager, including unstarted tasks - 00:00:00 didn't stand out clearly.

Actually, the server code - certainly the web server code, which is what we're talking about here - has been fully updated within the last month.

Then I stand corrected, but there was nothing about that in their news.

---

What about...

That would be plain and simple. My interpretation of "---" was always "not applicable" or "we can't decide yet" not 0.00.

As just stated, my personal choice would be the opposite - "---" implies something out of the ordinary, worth looking at.

I'd prefer

    switch($result->outcome) {
    case RESULT_OUTCOME_SUCCESS:
        switch ($result->validate_state) {
        case VALIDATE_STATE_INIT:
        case VALIDATE_STATE_INCONCLUSIVE:
            return tra("pending");
        }
        if ($result->granted_credit > 0) {
            return $string_to_show;
        }
        return "---";
    default:
        if ($result->granted_credit > 0) {
            return $string_to_show;
        }
        return "---";
    }

... but there was nothing about that in their news.

It was covered in Technical News - Backend upgrade scheduled for Wed Nov 18.

That's nice if you read their forums, which I do not. I did search through https://einstein.phys.uwm.edu/old_news.php prior to my post though.

An oversight of most BOINC front-end websites:
Links to News: yes
Links to Technical news: no

Also nothing about it in the Notices.

But letting it rest now.

---

scientifically speaking, there are the additional options of:

n.a. (not applicable)
n.d. (not determined)

and more colloquial:

tbd (to be determined)
tba (to be announced)

but of course in terms of credit you do get zero credit for an invalid, so 0.0 isn't really wrong.
Just that, as Richard stated, a string (any string) instead of a number would increase visibility in a table.

scientifically speaking, there are the additional options of:

n.a. (not applicable)
n.d. (not determined)

and more colloquial:

tbd (to be determined)
tba (to be announced)

but of course in terms of credit you do get zero credit for an invalid, so 0.0 isn't really wrong.
Just that, as Richard stated, a string (any string) instead of a number would increase visibility in a table.

We have "pending" for the non-final cases.

I'd prefer to reserve 0.00 for "credit was granted, but it was between 0.000001 and 0.004999"

Cancel my previous attempt at coding - if "---" is accepted, let's be explicit about it.

    switch($result->outcome) {
    case RESULT_OUTCOME_SUCCESS:
        switch ($result->validate_state) {
        case VALIDATE_STATE_INIT:
        case VALIDATE_STATE_INCONCLUSIVE:
            return tra("pending");
        case VALIDATE_STATE_INVALID:
        case VALIDATE_STATE_NO_CHECK:
            return "---";
        }
        return $string_to_show;
    default:
        if ($result->granted_credit > 0) {
            return $string_to_show;
        }
        return "---";
    }

Edit - but then manual credit - "Admin's Benificence" - wouldn't show up. Bother. Shouldn't be trying to solve problems and get ready to go out, at the same time. I'll leave you in peace for a few hours.

Back. Personally, I think it's better to distinguish between 'disqualified from credit - nul points' and 'valid, got credit, but only a tiny amount'.

I do have one project which awards credit even too low to display as 0.01 - Numberfields, three tasks today alone (pages may need scrolling to see zero credit).

I may have opened a can of worms here but i feel if a completed task has zero value, then 0 is the correct value to report.

I can imagine setting up an app to test something but award no credit.

I rather like 0, or 0.0 or 0.00.

It might look a bit funny, but perhaps that (funny looking) might be a good thing.

If the value is 0.0003 then report that on the smalls.

<meanders of track and hijacks own thread>
This sorted of started me thinking, and i guess at some point it has been raised about "negative credit". If a task is invalid, then based on premise it has consumed more project resources, it should be less creditworthy than a error, which in turn less than an abort.