Hi, I have a question: what is the usual method for calculating byte count (outside of tio)? I see a lot of answers from golfing languages such as Vyxal and Osabie that use 2 byte or 3 byte chars but count them as 1 byte (The method I use is open a node repl and do new TextEncoder().encode("œO").length //3 for example
Is this my output?
Decision problem: Is the input one of your output values?
Example: if input is "True" or "False", output "True", else output "False"
Basically, an interpreter just takes some string of bytes and does something with it. An SBCS considers every one of those bytes to be its own character, compared to UTF-8 which treats characters higher than 0x7f differently.
So you could, within strings, interpret those bytes as UTF-8 instead of using your code page if you wanted to
You could even invent your own UTF-8-like encoding
Not really. The thing is, "string" and "character" are a bit vague
You can't count all 0x10ffff characters in Unicode as one byte, because no encoding could do that. But you can count any 256 characters as one byte, or you could count something like 64 as one byte and 49152 as two bytes, or you could use UTF-8 or UTF-16 or even UTF-32.
I really want to use something like Huffman encoding for an existing golflang to make it shorter, but I tried on Husk and it just made everything longer :(
@RedwolfPrograms But it would, at least, give you the option of using a symbol that makes sense for the builtin rather than whatever digraph you had available.
@DLosc We could honestly do this already. Pick a character like ⍝ outside the codepage and replace all occurrences of some digraph AB with ⍝. Totally legal and it'd help with copy pasting maybe
I've tried 6 and 7 bit code pages, problem is, you end up with things like 14-bit programs, so for short programs it does no good, and for long ones the lack of more specific built-ins hurts more than it helps
One idea could be a code page that maps multiple characters to a byte
So it could be all ASCII, but with the golfiness of an SBCS
@Komali The basic rule we've landed on is this: For any program in an SCBS language, you must be able to create an actual file on disc with the claimed byte count that you can pass to your interpreter and it executes the claimed program.
Task
A reverse checkers position is a chess position where every piece for one player is on one colour and every piece for the other player is on the other colour. Your task is to find if the given (valid) position meets these criteria.
For example, this position does (click for larger images). E...
And our consensus is that bytes are octets, so presumably that implies you can't run your code on a non-octet system and still count it (unless you provide a way to map that code to bytes)
@RedwolfPrograms There are at least two ways to do this. 1) You can design a miniature embedded file system to store files in your language that can store files of non-integer byte counts sequentially. 2) Even if programs need padding functions don't, because the relevant score for a function is how much it adds to the program to declare/envoke it.
Neither of these is at all in conflict with the meta consensus, in fact they follow from our consensuses.
These two solutions are arguably actually one solution wearing two different faces.
This feels like something we need to explicitly discuss on Meta, given that at least Redwolf and I are surprised by it and thought the policy was something else. (Pleasantly surprised, in my case, but still surprised.)
Is this my output?
Decision problem: Is the input one of your output values?
Example: if input is "True" or "False", output "True", else output "False"
