Timeline for RANDEVU - Rust crate implementing a simple algorithm I invented
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 3, 2024 at 20:47 | comment | added | TypicalHog | @Setris I've made another post related to this (just in case your are interested, I don't wish to leech your time): codereview.stackexchange.com/questions/291897/… | |
| Mar 7, 2024 at 15:51 | comment | added | TypicalHog | @Setris Good suggestions! Thank you! | |
| Mar 7, 2024 at 2:13 | comment | added | Setris | @TypicalHog Relevant article: Parse, don’t validate | |
| Mar 7, 2024 at 2:12 | comment | added | Setris | "so it would have to be converted back to date and then back to string again before it is hashed" <- which is perfectly fine, because rdv will be cleaner and easier to maintain (and use) as a result. If you change the type of rdv's date parameter to be a date object, you won't need to write validation logic in the body of rdv, and the return type can remain as it is, u32. If you keep date as a string and add validation logic, you'll need to change the return type to a Result or allow rdv to panic, both which are not as clean alternatives compared to just using a date object. | |
| Mar 5, 2024 at 19:20 | vote | accept | TypicalHog | ||
| Mar 5, 2024 at 19:17 | comment | added | TypicalHog | "Nothing is being done on a daily basis - there is no timed automation whatsoever in the code. It just exhibits some date serialization and a spurious hash function." It's up to the user to decide how to use and implement the rdv function. They can run it once every day to calculate the RDV value for a single object they have, or many different objects. They can calculate the values for future dates, or past dates. They can use the function in a loop and keep calculating the RDV values for an object until they find the date where the value returned by the function is a specific value etc | |
| Mar 5, 2024 at 19:17 | comment | added | TypicalHog | The rdv function accepts a string and not a date because it is assumed the date will be stored in a file or somewhere else as a string, so it would have to be converted back to date and then back to string again before it is hashed. I guess I should add a check which would reject invalid dates and maybe allow users to either pass the date as a string or a date object itself to the function. | |
| Mar 5, 2024 at 19:16 | comment | added | TypicalHog | I do explain the offset is in days in the docstring: /// Returns current UTC DATE String in ISO 8601 format (YYYY-MM-DD), with an OFFSET i64 in days I see how my use of the word generic can be confused with the type being generic. The object is ALWAYS a string, but that string can represent ANY object (such as a movie, game, person, video, book, place, post, task etc.) So I call it generic since the algorithm can be applied to ANYTHING that can be represented with a string as opposed to just tasks or meetings etc. I do need to improve the README and explain stuff better. | |
| Mar 5, 2024 at 19:13 | comment | added | TypicalHog | Thank you for your time and answer! The function is named rdv, which is short for RANDEVU (name of the algorithm). You can think of it the same way as ETA stands for "estimated time of arrival" or BCE which stands for "before common era". I guess I should explain that better in the README.md file. The values generated by the algorithm are commonly prefixed with RDV when one is referring to them and using them for the intended usecases. If an object has a value 5 on a given day, the convention is to refer to it as RDV5. Example usage: "Hey Mike, XONOTIC has RDV5 today, wanna play?" | |
| Mar 5, 2024 at 11:35 | history | edited | user277802 | CC BY-SA 4.0 | added 136 characters in body |
| Mar 5, 2024 at 10:54 | history | edited | user277802 | CC BY-SA 4.0 | added 93 characters in body |
| Mar 5, 2024 at 10:48 | history | answered | user277802 | CC BY-SA 4.0 |