Yup. Eons ago I took a class on video production. One thing the instructor made clear from early on is pure color does not exist in nature. Nothing anyone's come up with to point the camera at produced a pure signal. This was before the days of digital where you can simply read the RGB codes of any pixel. A lot of stuff is so much easier these days (for you youngsters: video tape uses a helical scan system, the read and write heads are based on the assumption that the tape is moving across the head at a constant speed--you can't produce a clear image if there's any spin-up or spin-down going on. Thus the machine would spin up and synchronize both source tapes and switch from one to the other (or fade or such) during the vsync period. Careful planning, and you had to plan all your edits to minimize the number of times you copied stuff as the quality would go down a bit every time) but everything outside the electronics remains basically unchanged.
-
Features
The superiority of ternary computers?
- Thread starter excreationist
- Start date
bilby
Fair dinkum thinkum
- Joined
- Mar 6, 2007
- Messages
- 39,641
- Gender
- He/Him
- Basic Beliefs
- Strong Atheist
Lasers do. Pure and coherent.
No. AI coding assistance has been shown to be of negative value. The problem is code is harder to read than to write--to be confident that what the AI spit out is accurate is harder than simply writing it. It sounds like what actually helped is that GPT found somebody's solution--something you could have done without AI. If you don't understand what that solution is doing you probably have undetected bugs. AI is the modern day incarnation of cargo cult programming.
excreationist
Married mouth-breather
Actually the extensive changes it made resulted in no noticeable bugs. See post #18 for a summary for the large number of optimizations. It gave very elegant and easy to read code. I could even ask it to make parts even more elegant (and give it some code to keep). I can't even understand most of the original EzySlice code, let along make any significant optimizations. So anyway it reduced frame issues a lot - from about 140ms per frame to 10ms per frame. Those frame times are when there is an explosion, screen shake, 3 lifeforms being dynamically sliced into 4 body chunks, blood spray, blood splatter on everything, multiple death sound effects, etc and those things were all optimized. Those 10ms include all of the other things happening as well (rendering and AI, etc).
And in the past few days I still haven't detected any bugs in the game from its code. So GPT5 at least has made a huge difference for me. What is true about AI coding in the past isn't necessarily the case forever.
No those optimizations to EzySlice don't exist anywhere else. And it kept the additions my worker made. Also all of the other code it optimized was from myself. Also I asked for making EzySlice to be optimized for IL2CPP which is barely mentioned in Unity circles. This is a GPT5 summary of IL2CPP optimizations - so it is pretty technical - and my game still runs without issues (which often isn't the case for my own coding)
I don't even know what some of those things mean though that didn't matter when GPT5 just optimized it for those things.Code & API Usage
🗂 Memory & Data Layout
- Avoid hidden allocations
- Don’t use LINQ, foreach on non‑arrays, or implicit boxing in hot paths.
- Pre‑allocate lists/arrays and reuse them (pooling).
- Replace string concatenation in loops with StringBuilder or pooled buffers.
- Minimise Reflection
- IL2CPP keeps metadata for reflection, which costs memory and startup time.
- Cache reflected members or bake lookups at build time.
- Consider link.xml to strip unused metadata.
- Inline where possible
- IL2CPP does little automatic inlining for properties/methods.
- Use [MethodImpl(MethodImplOptions.AggressiveInlining)] on small, frequently‑called methods.
- Cache .Count or property values before loops.
- Avoid virtual/interface calls in hot loops
- These can’t be inlined and have extra dispatch cost.
- Use sealed classes or direct calls where performance‑critical.
- Struct packing
- Use struct for small, immutable value types to reduce GC pressure.
- Keep structs ≤16 bytes to avoid copy overhead.
- Use blittable types for interop
- Avoid managed object marshalling where possible.
- Reduce metadata bloat
- Strip unused assemblies and types.
- Use IL2CPP_USE_SPARSEHASH for faster metadata lookups in reflection‑heavy projects.
Last edited:
excreationist
Married mouth-breather
Note lately I've been using it to occassionally try and fix issues and optimize code. I normally do new functionality and organisation myself.
In my previous post it talked about LINQ - which I’ve used but I wasn’t sure how to avoid its use in an efficient way.
In my previous post it talked about LINQ - which I’ve used but I wasn’t sure how to avoid its use in an efficient way.
Last edited:
excreationist
Married mouth-breather
A month ago things have changed...
The prompt:
What it made from scratch:
It also fixed errors it came across while it was coding.
It can also organise code to be well organised/modular and easy to understand and write documentation, etc.
From about an hour in:
Shadowy Man
Contributor
What does “pure” mean in this context?
Not detecting any bugs does not mean there aren't.
I've been burned by a Y2038 bug when I was on the other side of the world when a fat-fingered salesman found it. (Would have worked fine as is if the value was treated as unsigned, would have produced a mis-sorted but usable result had it simply failed to note the error.)
And I think it was the original GTA that had a bug that lay dormant for decades until a Windows update exposed it. (Uninitialized variable on the stack, "unused" in one case and therefore not configured in the file--except the object spawner "used" it, to no visible effect so long as it was set to a sane value. It was picking up the value from the previous line, worked fine. That is, until a Windows update put one more word on the stack, the stack clobbered the value in memory and the object spawner had fits over the garbage from the stack.)
And what about the Ariane V initial launch? They used some code that had run fine on the previous version of the rocket, now the sensors returned more bits. There was a pre-launch routine that became moot at ignition, at which point nobody needed the answer anymore and the vibration of flight meant it was producing garbage. Except more bits, bigger garbage. Untrapped underflow on divide, crashed the processor. Backup processor takes over, gets the same garbage, also crashes. The controls lock at maximum deflection, the rocket tries to make a hard turn but suicided when the load caused it to break.
GPT found it. It exists somewhere, although maybe not all in one place.
The problem is that a 99% right answer is a wrong answer. That's why Tesla's "Full Self Drive" should not exist. A Waymo knows what it doesn't know--it may hit a situation it can't handle but it knows not to try. A Tesla doesn't.
excreationist
Married mouth-breather
Basis for claim that the number of bugs per line of code is constant regardless of the language used
I've heard people say (although I can't recall who in particular) that the number of bugs per line of code is roughly constant regardless of what language is used. What is the research that backs t...
Humans don't produce completey bug-free code either...
Anyway like I wrote, it can detect bugs/issues and fix them automatically...
Yeah, vibe coding looks impressive to people who can't actually write and review the code themselves.Actually the extensive changes it made resulted in no noticeable bugs. See post #18 for a summary for the large number of optimizations. It gave very elegant and easy to read code. I could even ask it to make parts even more elegant (and give it some code to keep). I can't even understand most of the original EzySlice code, let along make any significant optimizations. So anyway it reduced frame issues a lot - from about 140ms per frame to 10ms per frame. Those frame times are when there is an explosion, screen shake, 3 lifeforms being dynamically sliced into 4 body chunks, blood spray, blood splatter on everything, multiple death sound effects, etc and those things were all optimized. Those 10ms include all of the other things happening as well (rendering and AI, etc).
And in the past few days I still haven't detected any bugs in the game from its code. So GPT5 at least has made a huge difference for me. What is true about AI coding in the past isn't necessarily the case forever.
No those optimizations to EzySlice don't exist anywhere else. And it kept the additions my worker made. Also all of the other code it optimized was from myself. Also I asked for making EzySlice to be optimized for IL2CPP which is barely mentioned in Unity circles. This is a GPT5 summary of IL2CPP optimizations - so it is pretty technical - and my game still runs without issues (which often isn't the case for my own coding)
I don't even know what some of those things mean though that didn't matter when GPT5 just optimized it for those things.
🗂 Memory & Data Layout
- Avoid hidden allocations
- Don’t use LINQ, foreach on non‑arrays, or implicit boxing in hot paths.
- Pre‑allocate lists/arrays and reuse them (pooling).
- Replace string concatenation in loops with StringBuilder or pooled buffers.
- Minimise Reflection
- IL2CPP keeps metadata for reflection, which costs memory and startup time.
- Cache reflected members or bake lookups at build time.
- Consider link.xml to strip unused metadata.
- Inline where possible
- IL2CPP does little automatic inlining for properties/methods.
- Use [MethodImpl(MethodImplOptions.AggressiveInlining)] on small, frequently‑called methods.
- Cache .Count or property values before loops.
- Avoid virtual/interface calls in hot loops
- These can’t be inlined and have extra dispatch cost.
- Use sealed classes or direct calls where performance‑critical.
- Struct packing
- Use struct for small, immutable value types to reduce GC pressure.
- Keep structs ≤16 bytes to avoid copy overhead.
- Use blittable types for interop
- Avoid managed object marshalling where possible.
- Reduce metadata bloat
- Strip unused assemblies and types.
- Use IL2CPP_USE_SPARSEHASH for faster metadata lookups in reflection‑heavy projects.
excreationist
Married mouth-breather
I write and review the code myself. In the past I also reviewed the code of other people (mainly PHP). What do you think of post #26? Note that often these days there is a thing called "one shot" where the AI can successfully deliver what was asked in the first try.
excreationist
Married mouth-breather
I deliberately said "I still haven't detected any bugs" to imply that there still could be bugs. The main thing for my game is that it isn't noticeably buggy. Note that the Unity game engine itself can have bugs as well. In my previous post to you I quoted statistics about how common bugs normally are.
It could use implications from other languages, etc. They trained GPT5 a lot to be good at coding.
I think this was pretty insightful:
Or something a bit harder:invent some opcodes for a ternary computer
Thinking in Base‑3
A ternary computer works with trits instead of bits — each trit can hold three states (often represented as -1, 0, +1 in balanced ternary, or 0, 1, 2 in unbalanced ternary).That means opcodes can be designed to take advantage of three‑way logic and more compact encodings than binary.
Here’s a fictional but plausible set of opcodes for a balanced ternary CPU:
Design Notes
- Balanced ternary (-1, 0, +1) is often more elegant for arithmetic because negation is just flipping signs.
- Opcodes are shown as three trits for simplicity, but a real ternary CPU might use more for addressing modes or immediate values.
- Branch instructions can take advantage of the three‑way sign flag instead of just zero/non‑zero.
- A MAP instruction is uniquely powerful in ternary — you can remap each trit via a 3‑entry table in one go.
If you like, I can design a tiny ternary assembly program using these opcodes to show how they’d work in practice — maybe something like a ternary counter or a sign‑based decision tree. Would you like me to do that next?
invent some opcodes for a base 19 computer
Alright — let’s imagine a nonary‑plus‑ten style machine: a base‑19 CPU, where each “digit” of an instruction is a nonadecimal value from 0 to 18. With 19 states per symbol, even a two‑digit opcode space gives you 361 unique instructions — plenty of room for rich, specialized operations.
We can design this for balanced base‑19 (-9 … 0 … +9) so arithmetic and branching can exploit symmetry.
🖥 Example Base‑19 Instruction Set
Mnemonic Opcode (nonadecits) Description Special Base‑19 Twist LD19 0 0 0Load Nonadeword from memory into register Address in next word ST19 0 0 1Store Nonadeword from register to memory — AD19 0 1 0Add (mod 19) Wraps naturally at 19 SU19 0 1 1Subtract (mod 19) — ML19 0 2 0Multiply (mod 19) Handy for modular crypto (19 is prime) DV19 0 2 1Divide (mod 19) — INC 0 3 0Increment by 1 nonadecimal Rolls over at 18 → 0 DEC 0 3 1Decrement by 1 nonadecimal Rolls under at 0 → 18 NEG 0 4 0Negate (balanced form) Flips sign in -9…+9representationTST 1 0 0Test Value Sets flags for <0,=0,>0BRN 1 0 1Branch if Negative — BRZ 1 0 2Branch if Zero — BRP 1 0 3Branch if Positive — BRM 1 0 4Branch if Magnitude > n n in next undecit SHL 1 1 0Shift Left by n nonadecits n in next digit SHR 1 1 1Shift Right by n nonadecits — ROT 1 1 2Rotate nonadecits Circular shift NINV 1 2 0Nonadecimal Invert Maps 0↔18,1↔17, …,9→9MAP19 1 2 1Apply 19‑entry lookup table to each digit Great for encoding/crypto MODP 1 3 0Modular Power Raises regA to regB mod 19 NOP 18 18 18No Operation — HLT 18 18 0Halt Execution —
Design Notes
Prime modulus: 19 being prime makes modular multiplication, inversion, and exponentiation especially useful for cryptography and finite‑field math.
Balanced form (-9…+9) makes negation trivial and allows three‑way branching on sign.
MAP19 is a “vectorized” instruction — you can remap each digit in a word in one go, which is powerful for table‑driven transforms.
With 19 states per digit, you could reserve entire opcode ranges for domain‑specific accelerators (e.g., DSP, AI tensor ops, graphics).
If you’d like, I can sketch a tiny base‑19 assembly program using these opcodes — for example, a modular counter that cycles through all 19 values and branches based on sign — so you can see them in action. Would you like me to build that next?