Please let me know if you find any bugs.
Why not generalize it to support all bases between base 2 and base 36?
I’ll give it a try.
Also, you can reply to specific posts, not just the topic by clicking on the gray reply button under the post you want to reply to instead of the blue button. This works better because I will get a notification this way.
thank you
How’s this?
Please let me know if you find any bugs.
It works!
yay!
It’d be better to generalize it for every base; the user can specify the "alphabet’ the base uses.
Nice! One request though - can you remove the custom category? For just one block, it makes much more sense just to put it in the Operators category. Even if you add more blocks, its still the same color; so just put in Operators!
Nice project. I especially like the clarity on the difference between numbers and numerals, and the explicit conversion of the user’s numeral to a number as an intermediate step before then converting the number back to a numeral in the target base. You correctly use math operators (e.g., MOD) on numbers and text operators (e.g., JOIN) on numerals.
The actual code could be cleaner if you learn to love recursive functions rather than loops. If you’re interested, you can see my version here.
Added support for bases up to base-62.
Lists can now be used for the base and the numerical value.
Moved from the “Base” category to the “Operators” category.
I’ll give it a try.
Ehhh… this particular problem doesn’t really get all that much cleaner with recursion. Maybe it’s just because I stan dynamic programming, but I see nothing wrong with the iterative version.
There’s nothing wrong with it, but even just
will make the code cleaner than having both conversions in one script.
And then I claim
is cleaner than the loop: no extra script variables, etc.
Thank you for letting me know. I tried using a custom block with recursion, and the code certainly became cleaner. Thanks!
We have implemented a conversion history feature. This allows the system to reference recorded entries when performing conversions that match the history, thereby speeding up processing (though the speed of the initial conversion remains unchanged).
It looks like an optimization at first, but since you’re using a linear map for caching, each conversion is now O(n) where n is the size of the cache. Even if you converted a number that was already in the cache, it still takes O(n) to find that it’s in the cache.