Talk:Trigbf

Does [ require exact equality to zero to skip the block of code? If so then loops are of very limited use, because exact zero can not occur by any means except , or moving to brand new cell. --Blashyrkh (talk) 11:29, 21 July 2026 (UTC)

Yep. This esolang isn't designed for usability. --None1 (Nope.) 12:41, 21 July 2026 (UTC)

Yes, I understand that (and that's true for most of esolangs). Just needed a clarification to be sure I understand the limitations correctly. --Blashyrkh (talk) 12:59, 21 July 2026 (UTC)

It actually means that the language is not suitable for arbitrary input handling. It can tell U+0000 input character from non-U+0000 character (by "tell" I mean "execute different blocks of code"), but it can not tell U+0001 from U+0002. It can print different characters (and even different strings of characters of the same length) depending on the character entered, but it's not possible to run different branches of code. Particularly, Truth-machine with ASCII input (U+0030 or U+0031) is impossible in Trigbf. Meanwhile I believe that Quine is possible, but hard to find. --Blashyrkh (talk) 13:02, 23 July 2026 (UTC)

I have an idea for a quine, it seems simple enough. I'm trying to make my own interpreter first though. –PkmnQ (talk) 19:39, 23 July 2026 (UTC)

My idea:

CODE₁>>CODE₂>>CODE₃>>...CODE_N>> | <<[<<]>>[PRINT_CODE>MAKE_GT_SIGN..>]<<[<<]>>[PRINT_CHAR>>]

where each of CODE_i is one of 8 fixed-length sequences of {sct},

PRINT_CODE - sequence of {sct.} which prints the whole CODE_i depending on initial value produced by CODE_i for all 8 possible CODE_i (that's the hardest part)

MAKE_GT_SIGN - sequence of {sct} which produces ascii code of > sign starting from 0.0 initial value

PRINT_CHAR - sequence of {sct.} which prints one of {sct><[].} characters starting from the value left by PRINT_CODE

Each CODE_i corresponds to character of a program starting from the delimiting |

--Blashyrkh (talk) 08:01, 24 July 2026 (UTC)

And few notes:

- second printing rail loop may be directed backwards (shorter by few bytes because second rewind rail loop is not needed anymore)

- two approaches to look for PRINT_CODE, PRINT_CHAR and CODEs: brute force (iterate over all sequences, test each one) and constructive (based on arctan and 256/pi rational approximations).

--Blashyrkh (talk) 08:25, 24 July 2026 (UTC)

I was thinking of actually using a different encoding of characters on the tape, where e.g. s would be encoded as c>c> c>> c>> c>> c>> c>> c>> c>>, c would be encoded as c>> c>c> c>> c>> c>> c>> c>> c>>, t would be encoded as c>> c>> c>c> c>> c>> c>> c>> c>>, etc. I think this encoding (or anything similar with the idea of using eight bits, with each bit corresponding to one of eight characters) would make PRINT_CODE and PRINT_CHAR much simpler. –PkmnQ (talk) 11:04, 24 July 2026 (UTC)

Tricky. Yes, this approach enables loops/conditionals, but keep in mind that the tape (at least the parts holding the codes) is immutable for you while each code must be inspected twice. --Blashyrkh (talk) 11:09, 24 July 2026 (UTC)

I've finished my quine, it can definitely be golfed (I have a few particular golfs in mind), but it already works as it is now. It's outputted by the following python code:

x = "<<<<[<<<<]>>>>[sscstttssccttt.>cctcsstttstt...>>[<]<<[.>]>>]c[<[ccccttstt.<]<[>]<<<[ssctttsctt.<]<[>]<<<[ctcsstttstt.<]<[>]<<<[cttcstctttt.<]<[>]<<<[ssctstsccttt.<]<[>]<<<[csstcttctttt.<]<[>]<<<[cscccsccstttt.<]<[>]<<<[sscstttssccttt.<]<[>]<<]"
y = ""
for i in x[::-1]:
    y += "".join(["c>>>c>" if j == i else "c>>>>" for j in "ct[s]>.<"])
print(y+x)

The tape needs to be at least ~8000 (7776+a little bit) cells long for the quine to work, but I've verified that this works on both the mpmath and sympy (the latter having to be extended) interpreters. I won't put it on the page yet in case of further improvements (its current length is 10206), but it exists.

(As for my interpreter, I was trying to get something with intervals working, but since there already exist precise enough interpreters, I'll abandon it for now. Maybe I'll return to it in the future.) –PkmnQ (talk) 11:16, 26 July 2026 (UTC)

Keeping sum of log(abs(derivative)) is a bit easier than intervals (though less precise). --Blashyrkh (talk) 11:30, 26 July 2026 (UTC)

I invented a variant of this esolang Trigbf improved that may solve the issue. --None1 (Nope.) 10:39, 27 July 2026 (UTC)

Much shorter Hello, world!

cststtctcctt.tcccscscttt.ststcccstccttt..ttscctctcsttt.csssctststt.tcsccttstt.ctsccscstttt.tctsttssccttt.<csccttt.csccttccttt.tcctctctsttt.ccctccttt.scsscsttt.

It's worth saying that it may be shortened even further (challenge for golfers). --Blashyrkh (talk) 14:42, 21 July 2026 (UTC)

Since it was proven incorrect, here's the correct one. It doesn't use long chains of t, so it should work even without multi-precision math libraries:

cststtctcctt.>cststtcsccttt.>csttttcsccttt..>>ccsstcstttsttt.>cccscstttt.>ccsscsttstt.>ccctstsccccttt.<<<.<csccttt.<.<<<cccccsssscccttt.<csstctcttstt.<ccsscsttt.

--Blashyrkh (talk) 07:53, 26 July 2026 (UTC)

It works in both the old and the new interpreters, thx. --None1 (Nope.) 08:04, 26 July 2026 (UTC)

Original examples do not work

"Hello, world!" example outputs eight characters bytes (hex: 00 01 02 00 01 01 20 01), then crashes with exception ValueError: chr() arg not in range(0x110000). Similar troubles with other examples. --Blashyrkh (talk) 13:34, 22 July 2026 (UTC)

Weird, works on my computer but not on TIO, while your program, which works on TIO, does not work on my computer: It prints: "Hello, wrld" and raises the same exception. My Python version is Python 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)] on win32 and I use Windows 11. --None1 (Nope.) 01:53, 23 July 2026 (UTC)

Probably, different math library implementations (in python on in underlying libc or whatever). Mine is python-3.12.12, 64-bit linux, i5-11300H CPU (if it matters). The source of the problem is an error amplification by t, we shouldn't build such long chains of t without control of the value boundaries on every step (both in interpreter code and in bruteforcers). --Blashyrkh (talk) 05:53, 23 July 2026 (UTC)

The proper answer is that both interpreters (yours and mine) and generators (yours and mine) are incorrect. Language specification dictates to use "signed unbounded infinite-precision real numbers", but we use IEEE 754 approximations. --Blashyrkh (talk) 09:12, 23 July 2026 (UTC)

Like indefinitely-long tapes in brainfuck, implementing infinite precision real numbers is impossible, especially when we're applying transcendental functions (e.g.: trigonometric functions) to it. --None1 (Nope.) 09:28, 23 July 2026 (UTC)

Well, limited tape is certainly enough for "Hello, world!", for QUINE, for Truth-machine. Limited float precision should be enough for these program forms in Trigbf. Just a less naive interpreter is needed. An interpreter that keeps lower bound/upper bounds for each tape cell instead of single value is already an improvement because it could detect drastic precision loss and print runtime warning. Same considerations are true for generator scripts: when precision loss becomes critical, just drop the chain and start the new one. Then generator scripts would be able to generate code suitable for naive interpreter. --Blashyrkh (talk) 09:46, 23 July 2026 (UTC)

I made a new interpreter that uses mpmath and 100 decimal digits, it should be correct (at least in the text-printing tasks given). --None1 (Nope.) 07:03, 26 July 2026 (UTC)

My "Hello world": is it correct? --Blashyrkh (talk) 07:04, 26 July 2026 (UTC)

Your "Hello world" prints Helll and errors (the same behavior as islptng's interpreter), so it isn't correct as long as my interpreter is. --None1 (Nope.) 07:16, 26 July 2026 (UTC)

Probably a better interpreter

from sympy import Integer, sin, cos, tan
import sys
def tbf(code):
    s=[]
    matches={}
    tape=[Integer(0) for i in range(3000)]
    for i,j in enumerate(code):
        if j=='[':s.append(i)
        if j==']':m=s.pop();matches[m]=i;matches[i]=m
    cp=0
    p=1500
    while cp<len(code):
        if code[cp]=='s':tape[p]=sin(tape[p])
        if code[cp]=='c':tape[p]=cos(tape[p])
        if code[cp]=='t':tape[p]=tan(tape[p])
        if code[cp]==',':
            c=sys.stdin.read(1)
            tape[p]=Integer((ord(c) if c else 0)%256)
        if code[cp]=='.':print(chr(tape[p].round()),end='')
        if code[cp]=='<':p-=1
        if code[cp]=='>':p+=1
        if code[cp]=='[':
            if not tape[p]:cp=matches[cp]
        if code[cp]==']':
            if tape[p]:cp=matches[cp]
        cp+=1

I'm not sure if it really works, if not, SymPy sucks.

Blashyrkh's program outputs Helll�� and errors. None1's program RecursionError because he used too much functions. -- i  s  l  p  t  n  g  09:56, 24 July 2026 (UTC)

In fact, I think your interpreter is probably correct, because I wrote a new interpreter that uses mpmath and 100 decimal digits, and it behaved the same when interpreting Blashyrkh's program. I also generated an XKCD random number program (the only one your interpreter is capable of running in reasonable time) for my new interpreter and it worked in yours, too. --None1 (Nope.) 07:01, 26 July 2026 (UTC)

Your "shorter" HW is actually longer

It omits LF character at the end. If you add it (or remove LF printing from my HW), yours would become longer. But they are almost identical. My is shorter because I intentionally left unused cell between 'l' and 'o' to use it later for 'r' and hence save moves. --Blashyrkh (talk) 21:24, 26 July 2026 (UTC)

Oh, I see. I made the program not for golfing but for testing my new generator, I'll delete it. --None1 (Nope.) 09:30, 27 July 2026 (UTC)

Output of negative values

It should be explicitly clarified what should . do if current cell (rounded to the nearest integer) is negative or greater than 255. --Blashyrkh (talk) 21:36, 26 July 2026 (UTC)

UB. The Python interpreter errors when it's negative and prints as Unicode when it's greater than 255. --None1 (Nope.) 02:47, 27 July 2026 (UTC)