there would have to be two separate things: an encoder to the PPCGable program and a decoder. The reason why most of my attempts failed was because those two were too distant and one addition required multiple changes
@ASCII-only after 3 and 4 has been just pushed to the stack, it makes no sense to add those together so the disabling logic for "+" is when 2 constant things are on the stack reduce the tree so "+" has 0% chance of being next
So to make sure I understand this concept - there would be a translation where programs are represented by integers using Huffman encoding or something similar, utilizing different spellings of the same items and prediction of future terms to optimize the integer for size. There would be a many-to-one correspondence for encoding, but a one-to-one correspondence for decoding.
Because any less optimized programs would probably decode to different programs
So the first step is to figure out a way to represent optimizations then?
Anonymous
@dzaima True, it would be helpful to not require optimally-golfed code to be input. There would need to be a way to recognize different equivalent pieces to make those optimizations.
btw I think I even got a running thing for the commands of pushing a number and adding
the idea I've got for how it does the logic is that it's got a pseudo-stack with the probable things on it and each item has a value of is it constant, dependent on the input or random (idk if adding random things to the language would be worth it)
the biggest problem I can think of is loops and I think the way I'd deal with them is just optimize constant-seeing as from the 1st looping trough and after it just start as with a fresh stack (or if the looping amount is constant then happily run trough it)
@ASCII-only if there's a function which takes 4 inputs and the passed types are invalid (and there is nothing to overload it with) it should be disabled
Right so the source language doesn't have to be very golfy
So it can be more readable
number = Tester(lambda token: token.type == Number)
# in optimization list
[[number & constant, number & constant, "+"], lambda tokens: [Token(tokens[0].value + tokens[1].value)]
How does this look
number = Tester(lambda token, value=None: token.type == Number if value is None else (token.type == Number and token.value = value))
# in optimization list
[[number & constant, number & constant, "+"], lambda tokens: [Token(tokens[0].value + tokens[1].value)]]
[[number, number(1), "+"], lambda tokens: [tokens[0], "u"]]
@ASCII-only let's say there are 3 commands: push 2, push 4, add. So the program starts out by pushing 2, then pushing 3, then it disables the possibility of add (if the tree was a simple 1:1:1 then it'd be like reading a base 2 number instead of base 3)
@ASCII-only that's another reason why I stopped trying so many times - the filter was very non-general
Anonymous
@dzaima With a longer inheritance chain and an object that you only care about being an instance of a class midway through the chain
Anonymous
So like you have A -> B -> C -> ... -> Z, and you're dealing with objects of type Z. One filter would concern foo.some_Z_property, and another filter would concern foo.some_K_property, and you could do that without having to do casting with inheritance and polymorphism.
@mego oh, with that I meant "why not have it be the same class but simply with a variable saying if it's a constant or not" not "shouldn't it be a class of its own"
@SocraticPhoenix intelligently generates best options for the probable best options and intelligently disables ones that can be golfed or something like that
Yeah but like won't it always make sense to combine the literals here
To save 1 char for the plus
Anonymous
@dzaima It depends on the definition of +. It's probably best to just stick with integers while we figure out the details of what we're doing, and then work on adding different types and the interactions between them.
well as the definitions are more codey and not limited to Disables and you could make helper functions like typesEqual and bothConstants it should be shorter
@Downgoat paradigm decision will come after something works. So far it's mostly stack-ideaish but at least half of the idea could work on other paradigms.
