_/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
^+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"
"n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+
z""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n+n
n"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+"+
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\k@
Try it online!
Above code generates only an H
and operates as a platform by which modifications are made in order to achieve the listed score. Previous explanation in edit history.
Further?
Further.
"̌ * " +᷾ "̌ + . ᷾.
. . . . * . . .
n . . . " . . .
. . . . 1 . . .
. . . . ? . . .
͐. . + . " * " n̂
" * " n̂ n͐ + . .
This pattern is not reducible (ignore the spaces, they are used to align things so that the modifier characters are visible, as they don't combine with non-alpha characters; .
are NOP code points that can be subject to alteration). See this tio for a version without and this one for full accurate placement with spaces.
The pattern uses 74 bytes to represent -4
, or 18.5 bytes per -1
(up from the baseline 7 bytes). And we need a lot of -1
s. 117704 of them to be precise.
Proof of irreducibility:
- No entire rows can be removed, the
1?
lines appear to be, but due to the duplicated "
(one above, one below), this will result in the string *n͐
being multiplied against the next value on the stack, which (as the string is first) is not a valid action. the n..."
row can't be removed along with those two, as the n
is needed in the leftmost column
- There is no 8-way contiguous vertical collection of
.
that can be removed (reducing pattern width), as the lower right corner is inaccessible and no other .
exist on the bottom row.
- Directional change characters can't be removed without bypassing the needed number of
-1
operations. The closest we can get is changing the bottom row to "*"n+..
, but this would only be viable if the initial value "rb"n
(9141) minus the desired character was both:
- Divisible by 4
- Constructable from the available bytes (
e
: 2260
/"inch"
, !
: 2277
/"failure"
, the rest are not divisible by 4)
- Or if "rb" can be reduced to either "r" or "b" without adversely affecting the output (note that
"r "
and " b"
are not valid and will produce a -1
instead of a positive value). Given a vertical arrangement of the setup and output sequences and the ability to place these bytes such that this is prevented, this will not be possible.
- Six rows need to be prevented from wholesale deletion (partial deletion results in
"r."
or ".b"
where .
is a non-empty byte)
- Putting
rb
and k$
on paired rows
- entry and terminator each on their own rows
- A reflector on the top row above a
^
entry point protects the top row
- Any row with the
"
around rb
is automatically protected, as these bytes need to remain
Thus, the entry column is _^"rb"n͐
, the output/reset between letters is two columns, ̌.."rb"!͐
/ ᷾..$k..̂.
, and the last column (aligning k$
with the initial rb
) is ..;$k.̂.
(executed bottom to top).
The two columns allow the code to bloat slightly, adding seven more .
positions over keeping input and reset on a single column (k$"rb"ǹ
) as well as an additional (more expensive) ᷾
.
This represents code entry, one copy of the pattern, one output, and final output (a newline) and termination. Not the extra !
needed on the last iteration of the pattern so that flow is correctly handled (this costs a measly 13*3 bytes; along with 7*4 bytes at the end of rows that we can't enforce not being removed).
Finally, replace all .
and *
with
(or other four-byte codepoint).
I've done my best to accurately account for the overhead increases and costs after computing the raw pattern's byte sum, but I recognize I may be off by a small amount.
Ohgodwhy; it gets bigger
I believe this is irreducible.
DL.....DL..
R."p"...U..
..RD....D.L
.U.L"̌a"L.RU
RDU.\..../.
U.L...DL\.D
..ULUL...DL
...ULUL.D.L
....U...LRU
>.0....U../@
."R"h"D.R+U
.t...DL.UL.
."..D/..≠.D
.RU/LU..L.?
R.D....RU.n
U"z"᷾.R5URU.
..R:l͍U..U.L
Try it online!
Sequence >.0
simply to set the stack to contain an initial value (and should be considered ...
)
All the UDLR/\
would be replaced by their 2-byte modifier counterparts and every cell not otherwise filled with a command is given a 4-byte unicode character. This works out to (I think) 647 bytes to generate a single -1. On top of that, our initial value rises from "rb"n
(9141) to 914,100,000 by making each initial letter get constructed from "rb"nYC
. As YC
occupy space, they would irreparably damage the redirection pattern.
Roughly speaking (accurate overhead between letters not verified, but we're talking about a few dozen bytes at most), this works out to a score of 7,688,494,370,086 (7.6 trillion).
Breaking this would require finding a way to bypass the maze of pointer redirections without (a) breaking the pattern--as a large number of the paths redirect away an infinite loop or an invalid command--and still (b) generating a 5 character long string prior to hitting the n
, due to a :l͍5≠?
jump check. It costs a few bytes to make this check (11 bytes lost), but reinforces the durability of the pattern.
The string pathz
was chosen as a 5-character long sequence where every right-truncated string ("p", "pa", "pat", "path") was present in the word dictionary (meaning that when calling n
on it, a positive value will be generated), forcing the program to trace out a meandering route to pick up each letter before hitting the "z"
to get a string not in the dictionary. This can still be improved as paths
is also present in the dictionary (leading to a 6-length string pathsz
), but at this point I'm starting to look for something that will increase the byte count exponentially and searching the word dictionary for longer strings with the desired characteristics is tedious.
Unary
is banned? This question would be code-golf in Unary like languages. And it is almost impossible to post an answer in such languages: Since it is hard to prove the answer fit the requirement. \$\endgroup\$