ais523 - high effort answers

by the way, I'm pretty sure self-replicating programs do exist in Trianguish, for much the same reason that TC languages generally have quines, but they'd almost certainly be too large to run in the JS interpreter

@Adám believe it or not this is actually a Jelly builtin. although I needed to add a second builtin to get the output format to match

so it was only about 3 days' worth of work rather than the weeks it looked like it coudl take

but the secondary constructors are easier to build than I anticipated because you don't have to build the logic that determines whta to build, you can just leave that in its original location and send the instructions along a wire

it is fun to watch, though, using builder snakes to reach points to build things, and building secondary constructors to avoid a slowdown

tbf this construction probably isn't worth all 2500 – you could just award 500 on my most recent (on this account)

ah, but you aren't, looks like I didn't quite get online in time

@RydwolfPrograms: if you want to talk about Trianguish, I'm here

and other compressed constants

vyncode should ideally detect compressed strings and send them literally, rather than attempting to vyncode them

now I'm wondering if this is technically a compression algorithm, we call it "compression" but it is different in nature from something like gzip

this is unless the length of the output is implied by the length of the input, in which case obviously it doesn't get any shorter because the particularly-compressed encodings are all being used for shorter strings

get two leading zeros and you save two bytes, and so on

get a leading zero after compression and you save a byte

err, 254/255

yes, that'll happen 255/256 of the time

(in practice, most compression methods do waste encodings on things like headers and checksums. but generally have variants which don't)

even if the compression method isn't random, we're assuming that pi is, so the probability of hitting an particularly compressible sequence doesn't depend on which sequences it is that are particularly compressible

any, assuming that the compression method doesn't waste encodings

so about 36 bytes

err, not bytes, decimal digits

good luck finding it, though :-D

assuming that pi is random, statistically the most-compressible 100-digit substring of the first 10^14 digits of pi probably compresses to 86 or 87 bytes

which seems potentially quite usable in a problem like this, so it would be good to know whether or not it's allowed

I think at least one language has a builtin for 2π

but those aren't validity / improvement complaints, more an issue with the concept

and the former seems incredibly tedious, it's basically the codegolf equivalent of bitcoin mining

I'm not sure if it's so interesting for the answerers, the theoretically optimal strategy is probably either "brute-force digits of pi until you find a particularly compressible string" or just calculating pi from the start

also that link is broken, I meant nethack4.org/pastebin/… (for the improvements patch)

also I made a few changes to my local copy of the Trianguish interpreter in order to make it a bit more usable when working with larger programs: nethack4.org/pastebin/…; I don't know whether you'd be interested in them or not

unfortunately a full construction is a) so large and b) so slow that I haven't been able to build a full program, but there's a working demonstration of the only non-obvious piece, everything else is straightforward

@RydwolfPrograms Is this valid to claim your bounty? esolangs.org/wiki/Trianguish#Computational_class

(and sandsifter apparently found one in 2017, but it was kept secret for fear it might be used maliciously – I wonder if it's been fixed yet, and when it'll become public)

although it was possible to fix that one in software via doing really weird things with the interrupt table

the more famous one is 0xf0 0x0f 0xc7 0xc8, which was also a hard lock on the processor

I'm vaguely tempted to try running it on my processor to see what happens (although I expect it'd just immediately SIGILL)

huh, after looking up encodings for the halt-and-catch-fire instruction (defined as anything that requires at least a power cycle to get the processor back to working order), it seems that 0x0f 0x04 did that on the 286, and the opcode in question is still unused on Intel processors even nowadays

so they have some incentive to be accurate

although, the reason they provide these things is to allow programmers to figure out what their program is bottlenecked on at the machine-code/microcode level, thus allowing them to work around the flaws of the processor and thus produce better benchmark results

quite possibly :-D

but it's frustrating, because you can only check things that the processor manufacturer thought to measure, and often you have to rely on measurements that don't measure exactly what you want

and learn, e.g., how many CPU cycles your program ran for, or how many memory accesses they made, or how many commands ran on execution port 6, etc.

modern processors have a range of performance counters that just count various things happening internally, you can monitor up to four of them at a time

there's also the perf command (Linux-specific, there's probably a Windows equivalent) which lets you see what the processor is doing via collecting statistics on various parts of the internals, it can be a lot of fun

not 100% accurate but pretty close

it's reverse-engineered internal details for most x86ish processors

Agner Fog's optimisation guide is pretty good if you're looking for a single thing to read, though

but, most of this isn't secret, you can find it with a web search once you've figured out the right questions to ask

actually I think I vaguely knew about the kernel zero page beforehand

I learned them writing the FizzBuzz program