21–30 of 32 posts
Earlier quoted context omitted.
Does that output a string of bits, or decimal numbers?
It computes a list (as nested pairs in the standard lambda calculus representation) of Church numerals (the standard representation of natural numbers). See also the discussion of the 167-bit primes program output in the first link, which gives an impression of the overhead needed for output in decimals.
Huh, once you add a compiler step to turn normal code into "golfed" code, it feels like a different thing, with the goal being to write a compact bytecode format. This one seems mostly like a workaround for having to type weird Unicode characters, so it still seem "fair" to me whatever that means. But I wonder how much a normal java program can be auto golfed by playing with the bytecode output.
The alternate representation generally saves ~15%, as measured in bytes. However, I totally understand the argument about human-unreadable "golfed" code, which is why you can always use the plain ASCII representation if you want.
For instance, you can print fibonacci numbers in an infinite loop using this program. [1]
10Wb+Q
[0] https://github.com/tomtheisen/stax/blob/master/docs/packed.m...
[flagged]
Python FFI in Vyxal was neat because you could trivially import python libraries like sockets, or start doing FFI to C libraries with calls to Python's ctypes. It was a mess but it's satisfying just how many different cross-cutting concerns you could glue together with very little code, when most other esolangs don't provide much of a standard library.
With code golfing languages, there are inherent tradeoffs between code size and usability/fun. IMO the most important features for minimizing length (assuming the only rule is the interpreter must be published before the challenge) are:
* (in Vyxal) Efficient syntax. Not sure what state of the art is anymore but stack-based seems reasonable.
* (in Vyxal) String compression
* (not in Vyxal) Efficient encoding; Huffman coding at a minimum but ideally arithmetic coding using sophisticated machine learning to predict the next command. It's super inefficient to have each command be 1 or 2 bytes regardless of frequency.
* (not in Vyxal) Huge numbers of builtins; Vyxal has "only" ~560. Ideally every past code golf question and every OEIS sequence are their own builtin.
Vyxal might hit a sweet spot, but I'm skeptical that it actually score as well as other languages with more of these features.
I think the size of the interpreter for Vyxal should be included in the scoring, if we're going to be really consistent about this. On the other hand, if you're going to allow plaintext to be compressed into bytecode, why not include a Huffman encoder as part of the flow? The FizzBuzz example has a string splitter in it (apparently, I haven't read ALL the docs), just to get around quoting some strings, but quotes mig…
Code Golf categories are arbitrary anyways, and can be as strict or as permissible as the golf course designer likes. If you need the most raw representation of code size, how about a code golf category where you have to design the smallest physical computer that can perform a certain task?
> Who can make it the smallest?
I noticed that in Vyxel 2 the language allows you to grab arbitrary Python modules and make calls, but this doesn't seem to be available anymore in Vyxel 3. So I'm thinking you can make a smaller Vyxel 3 implementation than 2. Either way, both reference implementations are fairly large runtimes.
Earlier quoted context omitted.
Any defined runtime seems fair, though a real computer will always seem more canonical. The two parts that seem unfair to me: 1. There's hidden bits of information based on choosing one language over another that can't be counted. Imagine a family of 26 languages that are the same except the first letter is different etc. 2. Some of the golfing is in how good the language you picked is in their bytecode and not how c…
My motivation in defining BLC was to have the simplest measure of the complexity of things. That includes binary strings, natural numbers, tuples, lists, sets, and functions of those, as well as languages (according to their interpreter) and formal systems (according to their theorem enumerator) [1]. [1] https://gist.github.com/tromp/86b3184f852f65bfb814e3ab0987d8...
> Vyxal is an stack-based esoteric array language that is dedicated to dominating competition in code golf challenges. This means that it strips away all need for boilerplate, long function names and impractical source layouts. > Functions are a core part of Vyxal. They are first class objects, meaning that you can have functions on the stack, functions can take functions as arguments, and functions can return functi…
> strips away all need for boilerplate Looks like this includes special optimizations for common problems including hello world (kh) and fizzbuzz (kF), but not 99 bottles of beer. https://vyxapedia.hyper-neutrino.xyz/elements
Earlier quoted context omitted.
My motivation in defining BLC was to have the simplest measure of the complexity of things. That includes binary strings, natural numbers, tuples, lists, sets, and functions of those, as well as languages (according to their interpreter) and formal systems (according to their theorem enumerator) [1]. [1] https://gist.github.com/tromp/86b3184f852f65bfb814e3ab0987d8...
How does it compare to BrainPhoque, the language used in Learning Universal Predictors (Hutter 2024) to approximate normalized Solomonoff induction?
> programs containing unbalanced parentheses are made valid, in particular by skipping any additional ].
But that still leaves programs invalid programs like "[[[[".
From a theoretical viewpoint, its biggest flaw is the lack of an input tape, which makes it a non-optimal description method in the sense of [2]. In particular, while BLC programs are at most a constant larger than BP ones, the reverse is not true.
The version of BF that I interpret in [3] is still optimally universal, because its program delimiting fist unbalanced ] is followed by its binary input.
[1] https://arxiv.org/html/2401.14953v1
[2] https://gist.github.com/tromp/86b3184f852f65bfb814e3ab0987d8...
[3] https://gist.github.com/tromp/86b3184f852f65bfb814e3ab0987d8...