in reply to Re^2: Reputation: -4 (+-0.5 -3.5)
in thread Reputation: -4 (+-0.5 -3.5)

> Aren't votes integers?

They most likely are.

But before displaying them calculations happen °:

from node_rep_line

  14:   my $up   = ($N->{reputation} + $N->{votescast}) / 2;
  15:   my $down = $up - $N->{reputation};

[download]

Looks like reputation was -4 and votescast 3 at the moment of my observation.

Hence one votecast got lost ...

update

I seem to remember reading about a "multiple vote feature" (for janitors?) announced some month ago.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

°) @PmDevs I somehow "reverse engineered" this bug, because I was expecting a division by two. Search internal code for all code snippets with "vote" and narrowing the result to / 2 led me to this part.

Replies are listed 'Best First'.
Re^4: Reputation: -4 (+-0.5 -3.5)
by RMGir (Prior) on Jul 21, 2019 at 20:36 UTC
    Thanks, that explains it nicely!

    It's interesting that it's not a transient issue: the votes are still fractional, so an update to votescast was likely permanently lost rather than you just seeing "torn values". 

    Reputation: -8 (+1.5 -9.5)

    [download]

    Mike
[reply]
[d/l]
      > It's interesting that it's not a transient issue:

      Looks logical to me, one down-vote only made it to rep but not to votescast, the DB wont store any other info.

      Seems like the desire to show "up" and "down" votes separately, came long after the DB model was established.

      This explains also why the display of it can be toggled in the settings.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]

        the DB wont store any other info.

        It surely stores who cast the votes (to prevent duplicate votes). As such, there are two ways to update reputation as a vote is cast:

        • Increment or decrement it as appropriate.
        • Calculate it from the votes in the database.

        RMGir was pointing out the former approach was used; the latter would make the effect of the bug transient.

        Actually, the latter would avoid the bug completely.

[reply]
[d/l]

In Section Perl Monks Discussion