In a discussion about SBCSs and other code pages, fractional byte counts were briefly brought up. I brought up our consensus that fractional byte programs are disallowed, and it was pointed out that the consensus does not disallow functions in languages with fractional byte code pages from having...
You might want to add at the start that answerers need to pick two values as their possible outputs
@RedwolfPrograms You pick two values (e.g. true for your truthy value and false for your falsy value). When your truthy value (true) is given as input, output true. If anything else is given as input, output false
@user I have trouble imagining you as more than text and a geometric profile pic, but I'll imagine some random person who likes Scala and code golf getting candy and hopefully it'll be you
@RedwolfPrograms if your output value is "true" for acceptance and "false" for rejection, you should only output "true" if input is "true" or "false". something that evals truthily would wrongly be accepted by x=>!!x i think
@DLosc To narrow it down a little and improve my chances of being the one who gets candy, add in "hates broccoli", "hates cats", and "sleepy" to that description
But I will assume he looks exactly like me, and I will be awaiting my fleet of aircraft carriers with a bottle of water, a new laptop, and a sizeable nuclear arsenal
Thinking over about this sub-byte meta I've just realized a truly horrible way to make a language that is virtually impossible to score properly, and would likely create a incredibly stupid meta discussion. I'm just going to lock that away in the recesses of my mind and hope that it never comes up. :)
Ok I will say what it is once I come up with a solution I like. :) I don't think it's very likely that anyone will come up with it since it's based off of some observations I made a while ago when trying to implement a non-released esolang.
@WheatWizard So when you say "If you want to make a virtual file system that allows you to make files of non-integer byte sizes, and these files can be packed together without padding, so they truly take up a non-integer number of bytes, then you can do that. I think pretty clearly then your file is not taking up an integer number of bytes, so it's score is not an integer number of bytes.", you mean you'd be allowed to score full programs as a non-integer number of bytes if you (1/2)
wrote a file system that could store it on your disk?
That seems like it's basically the same as how functions would be scored, but with a little bit of like...unobservable-ness on top
A virtual file system here might be nothing more than a program which takes a file which can store multiple programs each of which can be run from the file. You don't even need like directories or all the stuff that goes into a file system to make it usable.
Like, if my language uses trits, I could write a program that stores trits on a simulated trit-based file system on a file on my disk, but it doesn't really seem clear whether the size of that would be counted as: (1) the size of the trits in bits, information-theory-style, (2) the size in bits that's used in the file to actually store the information, or (3) the size of the file that's used to simulate the file system
I guess you could have a language where calling a function takes enough bits to "fill up" a program to the next whole byte value, and it gets "implicitly" added to the end of a program, where the program is just the function body
Like if my "file system" program just takes a list of trit-based programs (some ascii representation I guess), concatenates them into one big ternary number, then converts that to binary and stores the bits as a file, how many of those bits belong to each of the inputted program?
Would that the be dependent on the files that were already in the system though? For bits it wouldn't, but it gets kind of weird with trits or algebraic encoding
@RedwolfPrograms Unless you are using something much more exotic than trits it holds true.
I do think that there is a certain potential to abuse this but 1) There are already ways to abuse systems e.g. "programs" made entirely out of empty directories, or inventing a language specifically to solve a problem. 2) I think we should optimize for sensible general purpose rules instead of worrying about hypothetical exploits.
@RedwolfPrograms I think it would depend, as long as the added part can have fractional bytes but the overall size is measured in whole bytes.
That's my hesitation about WW's answer for functions, too. Say I have a function that's 10.5 bytes. If my main program is 10.5 bytes, it has to be stored as 11 bytes, so adding the function adds 10 bytes to the overall size. But if my main program is 10 bytes, adding the function adds 11 bytes. So wouldn't it be accurate to say that the size of the function is either 10 or 11 bytes, depending on what the rest of the program is?
But the rest of the program could be anything (e.g. if you're mapping over the inputs explicitly or let mapping happen implicitly). I think you should consider just the function, separate from the rest of the program
I think there are some metaphysical issues here in terms of stuff like what information counts as a part of the program / function, that we simply cannot surmount. But I think that here we should "optimize for pearls". We have no evidence of any bad faith sub-byte exploits but we have plenty of evidence of legitimate languages that do interesting stuff with sub-byte encodings. For that reason I don't see any reason to penalize the legitimate languages on account of hypothetical languages.
3
TJ "Henry" Yoshi, went to my university and I have actually met them.
@WheatWizard I mostly agree with you, but we also have a history on this site of adding rules to cater to existing languages, which rules are then intentionally used (exploited?) by new golflangs. (Custom codepages and free flags come to mind.) So I don't think the hypothetical is very hypothetical.
@DLosc I guess my thought is sort of just let them. Competition is not meant to be between languages so you're not really cheating anyone. Sub-byte opimization might actually spice up competition in golfing languages since often times the difference between 5 and 4 bytes is immense. And allowing a further gradation there gives some room for people to compete.
@WheatWizard Hmm, so you'd basically just pack all your programs into one file and then put a list of (name, offset) pairs at the beginning, with sub-byte offsets allowed?
I don't know if it would make things unnecessarily complicated, as long as the process goes like:
1. Someone makes a file system simulator that can accept sub-byte files 2. Nobody actually has to use it, they just start claiming fractional bytecounts
Like...if we're going to do the fractional byte counts thing for full programs, we should just allow it without this weird file-system-simulator-that-dies-for-our-sins-so-we-can-all-claim-fractional-byte-counts concept