@Neil week.golf/challenge.php?id=1, click the light bulb, click the language logo to switch to Python, then click "Solution №1", it will shrink, then click it again and it will show you the code
Divs works too but it's hard to get to behave consistently between browsers. Canvas looks bad when zoomed in or you need to write a lot of code to fix the resolution. Plus the click and hover effects thing
@emanresuA This is the problem with "golfing servers" (also like code.golf and golf.shinh.org) as opposed to fora like ours. In order to work in the system, all programs have to use the same IO method, which means way too many bytes wasted on reading STDIN or whatever
it's just not fun
And so far they've all been bizarre two-in-one problems for no good reason
Ulam numbers alone would be fine, but then applying it n times is, IMO, a worthless addition
also "operation not permitted" (EPERM) normally means a technical limitation, not exactly a permissions thing (which would be "permission denied" (EACCESS))
@Zionmyceliaadamancy Especially as it isn't hard to add some kind of wrapper when adding a language, so that I/O is done in that language's most natural way. It isn't perfect, but it works most of the time
I mean obviously there's a bit of a difference because hgl has so much space that there's basically no filter. If something could possibly be helpful might as well add it.
Although something I realized more and more is that my time with hgl is a finite resource.
Hello! Is there a reason most golfing languages (that I'm aware of) use single byte characters, instead of ones with a variable amount of bits? Some builtins are a lot more commons then others, so it would make sense to have those be shorter, and you can just split the final program to bytes
@CommandMaster A lot of them do have two byte commands. fwiw until recently it was extremely difficult to get a fractional byte count, so 9 bit commands would usually cost just as much as 16 bit commands.
@CommandMaster I think it's because it's hard: both an inconvenient encoding to implement, and more importantly, very hard to know which builtins warrant which bit encodings.
but if you give a builtin a longer encoding, it won't be used much because it's not golfy, which will make you think it deserves a longer encoding, even if it doesn't
One thing I want to do is collect a corpus of Jelly answers and unleash a NN compression algo on them. It could be very useful in telling what sort of atom combinations are most useful.
I mean, ultimately, you could write plain ones and zeroes, which would directly correspond to the lengths of the builtins
I guess you could do it by using elements as "words", where the number of chars in the word corresponds to the bit length. Is that what you meant @WheatWizard
I once thought of an idea for a symbolic encoding for a language where every command is a word of up to 7 letters, and you separate words with tabs so they all have the same visual width
that's kind of the opposite
@pxeger I decided it wasn't that useful, especially because of string literals
In a normal language you can write the same function and put it anywhere in a file. However in this language it needs to align with the grain of the file to fit so functions cannot simply be translated around.
Infinite Fibonacci word code-golf sequence fibonacci string
The famous Fibonacci sequence of integers is defined as follows:
\$
F_0 = 0 \\
F_1 = 1 \\
F_n = F_{n-1} + F_{n-2}
\$
But what if we use this same recurrence relation to produce an infinite sequence of strings? Instead of addition, we'll ...
should i make it simpler by using one universal character (of their choice), or is the variety of chars (to make the arrow look like an actual pointing arrow) good?
Imagine two robots on the number line. If you choose a robot it goes forward one step with prob 0.5 and backwards one step with prob 0.5. You want to get either one of the robots to the point 10 with minimum total cost. The cost is the sum of the square of the number of steps each robot has taken.
since if the closer one has been dancing back and forward for 10000 moves the cost of moving it one more time might be more than trying the other one for a while
I've been debating making/installing a chat MathJax userscript for a while now. On the one hand it'd be useful, but on the other hand it's more annoying for mobile users and people who can't/don't want to install one