LIBERTY. CARDANO. RUST. AGNOSTIC ATHEIST. ASPIE. NERD. WEED. ADHD. OCD. SCHIZOID PD. FOSS. LINUX. PRIVACY. GAMER. DECENTRALIZATION. ANTI IP.

  • 19 Posts
  • 150 Comments
Joined 5 months ago
Cake day: February 3rd, 2024
  • TypicalHog@lemm.eeOPtoCode Review@programming.dev•[Rust] Implementation of an algorithm I invented - RANDEVUEnglish
    1·
    1 month ago

    It’s because I suck at explaining stuff.

    Imagine if you and a bunch of other people were huge fans or something, let’s say some videogame, but there are never enough people playing that game at the same time for it to function (imagine it’s a multiplayer game). Now, instead of a single person from the group remembering the game and playing it alone at random times when no one else is - imagine there was a “thing” where you put in the name of the object (in this example a game) and the “thing” spits out a number for that object each day. And every single person who has put in the same exact object (yes, kinda like a password) will get the same numbers out as everyone else. This thing outputs numbers randomly each day (but once again the random number is the same for everyone who put in the same object). There is a 50% chance the system will output 0, 25% chance it will output 1, 12.5% for 2, 6.25% for 3 and so on. Each number is twice as rare as the previous. This means we can expect a 0 about every other day on average, 1 every 4 days, 2 every 8 days, 3 -> 16, 4 -> 32, 5 -> 64, and so on. Ok, so now that we have multiple people getting the same numbers for that game each day - we can decide we’ll all come online and play the game when the system gives us a number higher than a certain threshold. For someone would would like to play that game about once a month, they might set the threshold to 5 (2^5 = 32), because we can expect the system to give us a number 5 or more about every 32 days. Another person who is a more hardcore fan might set it at 3 (2^3 = 8) and another user might have it set to like 8 (2^8 = 256). So, when the number hits 5 first 2 users would be notified and might decide to come play the game. When it hits 8 (every 256 days on average), a whole bunch of people would be notified (everyone who has the threshold set to 8 or less). Instead of random people playing the game on completely random and uncoordinated days and there never being a decent amount of people online at the same time. If everyone used this system - even though the game will be dead for most of the time, on certain days, when people get notified to play it they could all come online and play it at the same time. There might be no people playing it for months, but every once in a while (let’s say every 64 (2^6) days - when the system outputs 6) everyone interested could come play it together with everyone else who is using the system and the previously dead game could come back alive, if only once every 64ish days.

    This spreadsheet I made for a Minecraft server could maybe help with understanding the thing: https://bit.ly/CJRDV

    UPDATE: I have an analogy. Imagine you’re tossing a coin each day for a certain object until you get tails. Now, imagine if everyone else did the same, but the coin was magical and landed on the same side for all people who tossed it. People could toss the coin each day and decide to come do something, like play an obscure game or watch their favorite movie or YT video on a day where the coins lands head a certain number of time in a row (we stop tosses when we get tails). One day we may get 0 heads (aka we got tails on first throw), tomorrow we may get 2 heads before we get tails. In a week there may come a day where we got 6 heads in a row and assuming out threshold was 6 or less - we decide to come play the game. We can do this for any amount of objects, each object can be thought of as a different password which gives completely different and independent coins tosses. So, everyone who had it set to XONOTIC (a game), would see the coin land the same way.

  • TypicalHog@lemm.eeOPtoCode Review@programming.dev•[Rust] Implementation of an algorithm I invented - RANDEVUEnglish
    1·
    2 months ago

    Thank you for the answer!

    This version is a huge overhaul of the currently live version. I could’ve made a separate branch for it, but I’ve never done that before since I haven’t really had a need yet. I definitely need to learn how to do it tho, eventually (learn git branches).
    I’ve decided to create version 2.0 and just publish it once I think it’s good enough and when I’m confident I’ve finally decided on the final version of the algorithm.

    The algorithm uses NaiveDate and NaiveTime because it’s UTC-based. Users need to make sure they pass UTC time to the algorithm. Are you saying problems could arise if people pass a timezonelss local time to the function instead of UTC time?

    I might try your suggestion about using the match statement, just not sure how to go about it or if it’s even possible to do considering the way total is calculated, but it seems like it might not be very clean (or perhaps it will be even cleaner, idk). I haven’t really used macros yet. I don’t think we can go from lowest to highest due to the nature of the calculation, except if we go over all 32 bytes.

    2.0 * increment < 1 - total.fraq() checks if the sum of all increments from the current point on are able to contribute enough to make the whole part of the total increase. Btw, note the < instead of >.

    Example:
    Let’s imagine the increment is 0.1 and the total is 123.2. Since 2 * 0.1< 1 - 0.2 is true, we can conclude that even if we added all of the rest of the increments to the total (0.1 + 0.05 + 0.025 + 0.0125 + 0.00625 + … = 0.2), will never be able to change total enough to cause its integer part to increase from 123 to 124, thus, we stop. If the increment was 0.1 and the total was 123.9, we would continue because it is possible the rest of the increments (somewhere between 0.0 to 0.2) could make 123.9 go over 124.