Finding a Bloc STAR provider

Core Development
42

I’m confused, how is that different?

EDIT: I’m not confused, I’m just dumb, it needs to ignore the x parameter. Do carry on.

1 Like
43

And that’s over now. I don’t currently plan to run another announced test. Curiously, it says:

Election ended on December 14, 2024 at 1:31 AM UTC

So it ended about 3.5 hours after the configured ending time. Why? Don’t know, and no guess. My own time zone is UTC minus 5 hours, so that’s not it.

44

A few things are definitely wrong here:

  • I can’t see the results, I am getting an error message Error making request: 401: Does not have permission (1aedfc99)
  • For me the ending time is 2:40 AM UTC, or, most likely, the current time

So even if the software is good under the hood the UI and frontend in general has a few potentially serious issues before this site can be used. But a year of lead time and responsive developers should take care of this.

2 Likes
45

Thank you for trying! This one is shallow (I hope): I didn’t realize that I, as the election admin, needed to explicitly do something to make the results available after the election ended on its own. I clicked that button now, and the results should be visible to everyone now.

Bingo! Current local time for me too, but expressed in UTC (I messed up on what my UTC offset actually is before). I reported that via the “Feedback” button (lower right of page).

To my eyes, it’s gone very well so far for a beta release. I just contributed 100 bucks to help 'em out :smile:.

1 Like
46

Primarily for @ArendPeter and @larry:

More thoughts on randomization: my little 16-bit generator has such a short period that “most” permutations of a 10-element list can never be generated. Essentially the same is true of all PRNGs, but in the case of the Mersenne Twister, with monstrously large period, it takes lists with a few thousand elements before most permutations are out of reach.

A saving grace for us is that we don’t much care about speed. Things like the Twister can be called trillions of times in a program run and speed matters a lot. Here we only need to shuffle a list of candidates, at most once per ballot.

There is a standard way to greatly increase the period and improve quality, which maybe takes twice as long: apply a “Bays-Durham shuffle” to the underlying PRNG. The real cost is that the .get() method can no longer guarantee to return unique results across 65536 consecutive calls.

This isn’t a problem for shuffling a list, but would be if you want a candidate -> unique_int mapping. I’m proceeding under the belief that shuffling is fundamental, and that if you want a candidate -> unique_int mapping instead, it can be easily built from a permutation (e.g., map a candidate to its index in the shuffled list).

So my working code now implements Bays-Durham (just a few lines of easy code), and a form of Fisher-Yates shuffling. It’s still working hard to avoid any Python-unique features or libraries, uses no floats, and never creates an int needing more than 32 bits.

A chi-square test confirms that across 16 * math.factorial(10) tries at shuffling list(range(10)), all possible permutations were generated “about equally as often” as truly random shuffling would do. Same for smaller lists.

Testing this kind of thing is much harder than writing it. Especially including the time tearing out hair when tests fail :wink:

47

To my eyes, it’s gone very well so far for a beta release. I just contributed 100 bucks to help 'em out :smile:.

Thank you! :heart_hands:

Bingo! Current local time for me too, but expressed in UTC (I messed up on what my UTC offset actually is before). I reported that via the “Feedback” button (lower right of page).

Feedback received, will look into it. I also confirmed it on my end.

  • I can’t see the results, I am getting an error message Error making request: 401: Does not have permission (1aedfc99)

I’ll work to update this error too. Perhaps “Election has results set to private” or something like that. I should also make it more clear for admins when the page they’re viewing are only visible to them.

So my working code now implements Bays-Durham (just a few lines of easy code), and a form of Fisher-Yates shuffling. It’s still working hard to avoid any Python-unique features or libraries, uses no floats, and never creates an int needing more than 32 bits.

A chi-square test confirms that across 16 * math.factorial(10) tries at shuffling list(range(10)), all possible permutations were generated “about equally as often” as truly random shuffling would do. Same for smaller lists.

This is looking great! I’m happy to implement whatever version of TinyRand we end up with, and I’m also fine with moving away from candidate -> unique_int (we didn’t consider the possibility for the random generator to giving the same value multiple times :sweat_smile:)

Bays-Durham + Fisher-Yates sounds like a good way to go.

1 Like
48

I created a GitHub repository so we can keep ongoing developments off Discourse:

Feel free to contribute implementations in other languages, in the src/ directory.

One thing I haven’t thought about yet is how to “version” the code. Sooner or later, some material improvement will be made, but I think it’s crucial that older results still be reproducible here. @larry can think about that too :smile:.

2 Likes
49

The Python implementation now exposes a factory function,

tinyrand.get(version=tinyrand.DEFAULT_VERSION, seed=0)

which returns an instance of the class implementing the given version. Testing was changed to exercise all supported versions.

A useful addition was creating a version 1, which uses 26-bit state. Since that never creates an int exceeding 52 bits, it’s suitable for a language (like JavaScript) whose native “number type” is IEEE-754 double-precision floats.

I’m at the limit for list sizes I can exhaustively test. Checking lists of size 11 requires doing 16 * factorial(11) = 638,668,800 shuffles, and even under PyPy that takes close to half an hour - and requires RAM to store a dict with about factorial(11) = 39,916,800 11-element tuple keys. That’s pushing the limit on the RAM I have too.

I think this is cute :wink: - this is the entire implementation for version 1:

class TinyRand1(TinyRand0):
    VERSION = 1
    BITS = 26

    def __init__(self, seed=0):
        super().__init__(seed)

So, at least in Python, supporting multiple versions “forever” looks to be quite easy.

1 Like
50

And that’s been repaired. It displays the original end time now:

2 Likes
51

That’s great. The OFFICIAL RESULTS pages with the bar graphs look great as well. For documentation purposes, it might be a good idea to also include the starting and ending dates and times of the voting on each of those pages.

1 Like
52

Probably better to make UI suggestions directly to them, yes?

1 Like
53

Maybe, but rather than my sending a suggestion directly to them, it seemed preferable to either first allow an opportunity to form a consensus amongst us, or to allow Guido or you to make the decision. Too many cooks might spoil it.

Thanks for passing the suggestion on to them.

1 Like
54

To be clear, I didn’t pass on the suggestion. The piece I quoted was in response to @MegaIng, saying that I passed on his bug observation: that the end time reported was current local time rather than the time the election ended.

My interest is in ensuring their service will be usable for us, and bugs are the only things I feel obligated to report to them. I’m not passing on others’ “UI improvements” that aren’t addressing clear errors.

It’s their project, and they have to balance “feature requests” across all their users. To do that, they need to hear from users directly.

I’m not saying I disagree with your idea (I don’t), but am saying I’m not a “contact point” for their project. @ArendPeter is, and may - or may not - notice your suggestion when he browses this topic.

I personally don’t want to see this topic become like an Ideas topic, with a hundred people bike shedding UI ideas, nobody responsible for “doing something”, and probably never reaching consensus anyway :wink:.

3 Likes
55

Ah, I see.

OK, will send the feedback to them directly.

1 Like
56

Thanks! I got the feedback. It makes sense to me as well :slightly_smiling_face:

But yes, although I will do my best to keep up with this thread, please don’t be shy about using the feedback button on the website. I’m happy to receive all feedback (UI improvements, bug reports, general suggestions, etc), and that’ll be the best way to ensure that it’s on my radar

3 Likes