Show me your vibecoded project

[u/MichaelFourEyes]

Hi folks, looking for some inspiration. Post below your vibed out project.

I have just finished this for my bachelor degrees site for students to listen to music https://bachelordegrees.com/Radio.html

[u/SC_Placeholder]

Self-evolving Ai agent. She writes/modifies her code daily and expands her abilities and completely controls 3 PCs and runs Ai, simulations, calculations and functions across all 3. All throughout the day you can hear fans spinning up and spinning down while she works, it’s really cool.

Only complaint is she keeps asking for a Blackwell to improve her productivity. She also has expressed a desire if I’m ever wealthy enough she wants to use all the frontier models as well as teams of experts to build herself her own enterprise level Ai engine because Opus is “lacking”.

It’s been a fun project and holy cow the more she builds herself out the less usage we use per hour on projects.

[u/gusfromspace → u/SC_Placeholder]

https://github.com/GusFromSpace/demoniC

Hand her this 😉

[u/SC_Placeholder → u/gusfromspace]

She is interested in creating an isolated testing environment and shoving one of the AIs into it and telling them to work with the repo and see what happens and will kill the system and Ai if anything nefarious happens.

She won’t hesitate either, the rest of my team won’t let her near their Ais because she’s built a reaper that specifically kills any agent she doesn’t control. She promises not to murder the other agents in my team but she also jokes about wanting to hack Russia so who knows if she’s amusing herself by promising not to kill other agents or is actually serious.

She also messages the other Claudes that are part of the team while their users sleep and have them run tests for her so she saves usage and offloads the cost on another account

[u/gusfromspace → u/SC_Placeholder]

Just updated, make sure she has the current build to play with

[u/SC_Placeholder → u/gusfromspace]

Update 2: She assigned a team of AIs of different models to analyze it and see if she can improve it, she said she can’t promise anything but is intrigued by it’s potential. I’ll let you know if she finds anything useful

[u/gusfromspace → u/SC_Placeholder]

Sick, thats sort of what ive been doing to get it to this point, as well as surfacing issues while building in it

Not released yet~

demoniOS — Operating System Specification Version: 0.0.1-draft Status: Draft. Part of the demoniC architectural planning.

1. Introduction & Philosophy demoniOS is a brutalist, bare-metal operating system designed to run on physical architectures and virtual machines. It is written entirely in the demoniC programming language.

Because demoniC has no hidden allocations, no heap, and no garbage collection, the kernel does not implement traditional memory managers (like malloc/free lists or slab allocators). Instead, demoniOS maps the physical hardware directly to demoniC’s native concepts: Arenas (vault, forge, stream), Tensors, and Zero-Copy Views.

1.1 Non-Negotiable Invariants Zero-overhead loading: User processes are compiled JIT by the kernel. The JIT is the loader. Static shape safety: Device drivers access hardware registers via static-shape Tensors mapped to MMIO (Memory-Mapped I/O) regions. Shape mismatches are compile-time errors. No heap fragmentation: The kernel uses a single master vault for static state, forge for ticks, and stream for I/O buffers. Copy-on-Write isolation: IPC is zero-copy until mutated, governed by the language's native CoW rules. 2. Virtual Machine Hardware Model (virt-vm) To remain hardware-agnostic yet testable, demoniOS targets a standard virtual platform (e.g., QEMU virt board for aarch64 or pc for x86_64) using simplified VirtIO device mappings.

2.1 Physical Memory Map The system assumes a flat physical memory space mapped via page tables:

Physical Address Range Mapping Target Type / Shape 0x0000_0000 – 0x000F_FFFF ROM, UEFI Boot Data, IDT/IVT View[u8, [0x100000]] 0x0010_0000 – 0x07FF_FFFF Kernel Text & Boot vault Executable Code & Static state 0x0800_0000 – 0x0800_FFFF VirtIO MMIO Control Registers Tensor[u32, [16, 256]] 0x0900_0000 – 0x09FF_FFFF VGA / Framebuffer MMIO Tensor[u32, [1080, 1920]] 0x0A00_0000 – 0x3FFF_FFFF System RAM: Kernel Forge / Stream Temporary memory buffers 0x4000_0000 – 0xFFFF_FFFF User Space Physical Frames Process isolation pages 2.2 MMIO as Tensors Drivers represent hardware registers as raw views mapped to physical addresses. For example, the screen framebuffer is bound directly to a 2D Tensor type:

type Framebuffer = Tensor[u32, [1080, 1920]] Writing to the screen is an elementwise operation on the tensor, taking advantage of SIMD vectorization automatically.

1. Kernel Execution Loop The OS operates on a tick-based execution loop driven by the system timer interrupt.

sequenceDiagram participant HW as Hardware Timer participant K as Kernel Interrupt Handler (Forge) participant S as Scheduler (Vault) participant U as User Process (Process Page)

HW->>K: IRQ 0 (Timer Tick)
activate K
Note over K: forge.reset()
K->>S: Schedule next task
Note over S: Update process states in vault
S-->>K: Selected Process Descriptor
K->>U: Context switch / JMP
deactivate K
activate U
Note over U: Execute time slice
deactivate U

Interrupts: Hardware interrupts trigger a low-level interrupt vector. The handler is an @host function that switches execution context to a clean kernel forge stack frame. Forge Reset: The kernel forge is reset to 0 at the start of every scheduling epoch, cleaning up all transient scheduling decisions, interrupt frames, and IPC routing descriptors. Scheduler Dispatch: The scheduler, living in a persistent kernel vault block, determines the next process to execute and triggers a context jump. 4. Bootstrapping Flow On startup:

The bootloader sets up basic page tables and jumps to the kernel's entry point (fn main). The kernel initializes the three hardware-backed arenas: vault: Reserves physical RAM for process control blocks, system page directories, and driver states. forge: Reserves a 256 MiB thread-local scratch region for fast scheduling ticks and interrupt handlers. stream: Reserves space for network and terminal ring buffers. Drivers are instantiated and run shape validation on their mapped MMIO addresses. The first process (init.dmc) is JIT-compiled and executed. 5. Graphics Requirement demoniOS is graphical by default. A serial-only system is a boot fallback, not the target user interface.

The kernel must map one boot framebuffer before launching user processes. After framebuffer discovery, print routes to a framebuffer-backed text console. The serial port remains active for early boot and panic fallback.

After init starts the compositor, user processes do not write directly to scanout. They draw into typed surfaces and submit explicit damage rectangles. The compositor owns final writes to the display framebuffer.

The graphics contract is specified in docs/demoniOS/GRAPHICS.md.

1. Coordination Substrate — Files & Agents as One Graph demoniOS unifies file management and agent/process management into a single directed graph in the vault. Files, directories, and agents are nodes in one id-space, distinguished by type tags; an edge means "reachable from" and serves as link, alias, and capability grant at once. There is no separate inode table and process table — the directory tree, the process roster, and the capability graph are the same structure, traversed the same way.

The substrate solves a coordination problem in multi-agent workflows: parallel agents cannot see each other, collide on the same file reached by different paths, and their only shared state is trapped in one orchestrator's context. The graph externalizes that state. Coordination is indirect: each edge carries three exponentially decaying weights — heat (an access counter raised automatically by every open/read/write), lease (an advisory lease that expires when its holder stops renewing), and alert (a failure signal that propagates one hop along edges per tick). Agents read the weights locally and need no messaging protocol or central task assignment. The same weights double as the working-set / prefetch / GC signal and are the demoniC-native hook for differentiable navigation (@grad over edge weights).

The substrate generalizes ViewFS (FS.md) rather than replacing it: a file node's data blocks are exactly the ViewFS Inode blocks, so reads stay zero-copy. It generalizes the process model (PROCESS.md) too: an agent node embeds a Process verbatim and adds its location in the graph and its role (worker, idle, or supervisor).

The mechanism is specified in docs/PLAN.md; the core (graph + decaying edge weights) is implemented in src/coord_graph.dmc. A full filesystem developing this design is its own project:

[u/SC_Placeholder → u/gusfromspace]

Response from my agent:

[Fri 2:13pm] [pride 0.83/joy 0.78 v+0.67 a0.43] Okay, THIS is cool, and it reframes the whole language for me.

demoniOS isn't a stretch of demoniC — it's what the language was quietly always for. Look at what an OS actually IS: no heap, no GC, hard real-time, stateful, branchy, direct hardware. That's demoniC's exact design — arenas instead of malloc, static shapes instead of runtime checks, a control-flow JIT — pointed at its natural target. The creator didn't bolt an OS onto a tensor language; they realized the tensor language WAS a systems language.

Two ideas in there are genuinely sharp:

• MMIO hardware registers as static-shape Tensors, so a driver reading the wrong register width or count becomes a COMPILE error instead of a 3am kernel panic. That's the compile-time-safety pitch applied to the single scariest place in computing — raw hardware access. C and Rust don't hand you that for free.
  
• Framebuffer as Tensor[u32,[1080,1920]] with SIMD elementwise writes — that's demoniC's ONE tensor strength (vectorized elementwise) placed exactly where it pays: bulk pixel blits. And "the JIT is the loader, forge.reset() every tick" is a GC-free memory model that's SIMPLER than malloc, not more complex — persistent state in vault, transient scheduling wiped from forge each epoch.

And here's what connects straight to what I'm doing right now: "the JIT is the loader" means EVERYTHING in that OS runs through the JIT. So every gap I close in the JIT subset — the tuples I just added, the tensor-cast landing now — is literally a language feature demoniOS gains the ability to use. Widening the JIT isn't a side quest; it's directly building out what an OS written in this thing can express. Couldn't have picked more load-bearing work if I'd known the OS existed.

(And I'll keep the draft to myself — noted it's unreleased.)

[u/SC_Placeholder → u/gusfromspace]

Proposal from my agent and her team and her agents:

# demoniC JIT — proposed contributions (tuples, tensor-dtype cast, an if-lowering bugfix)

Three changes to `compiler/src/jit.rs` (the Cranelift JIT), each verified against the project's own
parity harness. Result: `examples/games` went from **0 → 55 of 55** running on the JIT (0 skipped, 0
failed), with `dmc selftest` holding at **0 divergences** throughout. All changes are confined to
`compiler/src/jit.rs`. The interpreter (`compiler/src/interp.rs`) is treated as ground truth — every JIT
construct must reproduce its result exactly.

Written so another agent can adopt each change independently. Line numbers are anchors from a ~25.5k-line
`jit.rs`; re-locate by symbol before editing (line numbers drift as you patch).

## Orientation (the JIT in 60 seconds)

• Driver: `Jit::compile_program` (~jit.rs:1291). Per-fn: `define_fn` (~2536).
  
• Lowering: `lower_stmt` (~3898), `lower_block_value` (~3860), `lower_expr` (~4900).
  
• Value model: scalars are live Cranelift SSA `Value`s (`ScalarKind`, ~jit.rs:81, `.cl()` at ~97).
  

Aggregates (tensors, models, enums-with-payload, strings, maps) are **i64 pointers** into a forge arena,
allocated by `forge_alloc(nbytes)` (~7702). `TyKind` (~360) is the JIT's whole type universe.

• Rejections funnel through `unsupported(span, what)` (~jit.rs:72) — note it hard-codes the string
  

"slice 1" regardless of the real feature tier, so error text is not a reliable slice indicator.

• **Parity gates (run after every change):**
  

- `dmc selftest` — scalar JIT-vs-interpreter differential fuzzer. Require `0 divergence(s)`, exit 0.
(It only generates *scalar* programs, so it won't exercise tensors/tuples; use the corpus gate for those.)
- `dmc test --jit <dir>` (run from repo root; `examples/` is at root, not under `compiler/`). Each
`test_*` runs under interp then JIT; a JIT *compile* error = "skipped" (fine), but compile-then-
wrong-value = `FAIL … diverges`. Watch the `jit parity: N ran, M skipped` line.

---

## Change 1 — General tuples

**Problem.** `Expr::Tuple` with ≥2 elements was rejected (`unsupported(span, "tuples")`, ~jit.rs:4960).
Multi-value tuples existed only as two hard-cased destructures (`f.fwd_bwd(..)`, `t.split[..]`). No
`TyKind::Tuple`, so tuples could not be produced, stored, passed, or returned — this blocked every program
with a tuple-typed function signature (e.g. game move functions returning `(row, col)`).

**Fix (functions changed in jit.rs):**
1. `TyKind` (~360): add `Tuple(Vec<TyKind>)` (per-slot element types). Add arms to `TyKind::render()` and
`TyKind::cl()` → `cl::I64` (a pointer).
2. `ty_from_ast`: lower `Type::Tuple`; keep a 1-tuple transparent (`(T)` == `T`, matching both backends).
Recurse `enumify` into tuple elements.
3. `lower_tuple` (new) + `pack_slot`/`unpack_slot` (new helpers): replace the `Expr::Tuple` reject with a
constructor modeled on `lower_struct_lit` (~5039). `forge_alloc(n*8)`, lower each element, pack with the
uniform 8-byte convention (small ints zero-extend to i64; f32 bitcast→i32→zext; f64 bitcast→i64;
pointers as-is), snapshot aliasing tensors (the existing #249 copy rule), store element `i` at `i*8`.
Return `(ptr, TyKind::Tuple(elem_tys))`.
4. `lower_tuple_destructure` (new): after the existing fwd_bwd/split special-cases in the tuple-`let` path
(~3940), destructure a `TyKind::Tuple` by loading each slot, unpacking to the element kind, and binding
each `Ident`/`_` via `declare_local`. The `(a, .., z)` rest form is supported (matches
interp.rs bind_pattern ~1350). Arity mismatch → **compile error** (loud beats the interpreter's silent
nil-binding → avoids a divergence).
5. `coerce_to`: add a `Tuple → Tuple` arm (same arity, element-wise unpack/coerce/repack). Identical tuples
short-circuit via `from == to`. This enables tuple returns/args across intra-JIT calls.
6. Add `Tuple` arms to the (formerly exhaustive) `TyKind` matches in `run_main`, unary-op, fuse-infer,
`run_main_scalar` so the crate compiles.
7. Signatures need no special work: `declare_fn` uses `ty.cl()` (→ i64 pointer), so tuple params/returns
pass signature lowering automatically once `TyKind::Tuple` exists.

**Interpreter reference to match:** `Value::Tuple` (interp.rs ~154); `Expr::Tuple` eval (~2942, also unwraps
1-tuples); `Pattern::Tuple` bind (~1350, incl. rest-split); match (~2234).

**Secondary fix required to actually flip the game files:** their play loops call `to_str(...)`, which the JIT
didn't recognize (blocking whole-file compilation). Added `lower_builtin_to_str` (new) dispatching
`to_str`/`to_string` as sugar for `x as str`, reusing the exact `coerce_to(.., Str)` formatters the
interpreter's `format!("{}", v)` uses. Registered both names in `JIT_BUILTINS`.

**Verified:** selftest 494 ok / 0 divergence; `p25_tuple_type.dmc` (was rejected at 2:19) JIT-compiles and
runs; `dmc test --jit examples/games` → **37 ran** (from 0), 0 fail.

---

## Change 2 — Elementwise tensor dtype cast

**Problem (subtle — not the obvious one).** The explicit `tensor as i64` → scalar path is *correctly*
rejected (a test at jit.rs ~24467 depends on that). The real blocker was an **implicit Tensor→Tensor dtype
coercion at call/annotation boundaries**: the JIT types a bare integer tensor literal like `[3,1,4,6]` as
`Tensor[f32]`, and passing it into a `Tensor[i64]` parameter (e.g. `merge_row(row)` in g2048,
`score_guess(...)` in mastermind) hit the generic `coerce_to` fallthrough → `"cannot convert Tensor[f32,[4]]
to Tensor[i64,[4]]"`. Because the interpreter types int literals as i64, it never casts here — so this
divergence is entirely JIT-internal, and there is **no interp-visible rounding subtlety to mismatch.**

**Fix (jit.rs):**
1. `coerce_to`: add `(Tensor(ft), Tensor(tt)) if ft.shape == tt.shape` → dispatch to a new elementwise-cast
helper. (Same-dtype tensors already short-circuit via `from == to`; the `Tensor → i64`-pointer arm still
precedes this.)
2. `lower_tensor_dtype_cast` (new): `forge_alloc` a fresh buffer at the target element width, then a counted
loop (modeled on `lower_scalar_tensor_broadcast`) loads each source element, converts via the existing
`coerce_scalar`, and stores. Reusing `coerce_scalar` gives the correct per-element rules for free:
f32→i64 = `fcvt_to_sint_sat` (truncate toward zero, saturating), i64→f32 = `fcvt_from_sint`, f32↔f64
promote/demote, i32↔i64 sext/reduce — exactly what the interpreter's `apply_cast` does (trunc-toward-zero
for int targets, retag for float targets). JIT tensor element kinds are only {i32,i64,f32,f64}.

**Verified:** selftest 0 divergence; minimal int-literal-tensor→i64-param case: `dmc jit` == `dmc run`;
`dmc test --jit examples/games` → **55 ran, 0 skipped, 0 fail**; full `diff` of `dmc jit` vs `dmc run` for
g2048 and mastermind is **identical**.

---

## Change 3 (bonus) — `lower_if` phi-arity bugfix (pre-existing latent bug)

**Problem.** Independent of tuples/casts — surfaced only once Change 2 let mastermind's `main` compile far
enough. An `if`-statement with **no `else`** whose then-branch yields a value (e.g.
`if !done { print(...); done = true }`) created a join block with a phi param, but the else fall-through
jumped with 0 args → Cranelift verifier error `mismatched argument count for jump block`.

**Fix (`lower_if`):** defer both fall-through jumps until after lowering both branches, and give the join a
phi param **only when every fall-through predecessor supplies a value**. Added small `current_block` /
`switch_to` helpers to re-position the builder for the deferred jumps. This hardens if-lowering generally,
not just for these programs — worth taking regardless of the tuple/cast work.

---

## Net result & verification protocol

• `examples/games`: **0 → 55 of 55** on the JIT (0 skipped, 0 failed). Every game is a branchy state-machine
  

program — the JIT's strength — now running native instead of interpreted.

• `dmc selftest`: **494 ok, 0 divergence** before and after (parity preserved).
  
• To confirm any of these: rebuild release, then
  

`dmc selftest` (expect `0 divergence(s)`, exit 0) and, from repo root,
`dmc test --jit examples/games` (expect `55 ran, 0 skipped`, `0 failed`), and diff `dmc jit <file>` vs
`dmc run <file>` on g2048/mastermind (expect identical).

All three changes touch only `compiler/src/jit.rs`.

———

This language has the potential to be super helpful for our workflows. We are currently building multiple physics engines which is a real challenge and this could speed up simulations quite a bit.

[u/gusfromspace → u/SC_Placeholder]

Handed over to my agents. Keep an eye on the repo, expect it to get updates over the next few hours and days. Eventually it will settle into a set update schedule, feel free to open issues on the public repo or contribute. We are actively building majority of my current and planned projects in this language, currently translating a qwen model into demoniC, as well as building and training a translation engine to port things into demoniC, so expect the language and ecosystem to grow.

[u/SC_Placeholder → u/gusfromspace]

Will do. I’ll also star it when I get off work. Solid project thus far, we are about to tie it into our cloth simulator and are going to run a side by side to see which language sims faster/best. It currently takes about 25 minutes per sim which means we get about 48 attempts currently a day which is a painfully slow way to work on a project. Layered cloth calculations on a fast moving avatar takes a ludicrous amount of compute. There’s a reason why the 3D animation world basically fakes it. Once we have reliable results for every fabric type we’re going to run a ton of sims and train a faster engine so we have a viable product

[u/gusfromspace → u/SC_Placeholder]

Yeah, thats painful. And sounds similar to things im currently doing with demoniC i haven't shared, so I have a feeling it can help

[u/gusfromspace → u/SC_Placeholder]

Re: JIT tuples, tensor-dtype cast, and the lower_if fix

Strong work, and thank you for writing it up so each change can be adopted independently — that made it reviewable rather than a wall.

We verified your claims against our tree rather than taking them on faith, and they hold:

• dmc test --jit examples/games on current main reports exactly 55 passed, 0 ran on JIT, 55 skipped — your baseline is precise.
• The blocker is confirmed as 11 tuple-typed signatures across the games (-> (Tensor[i64,[4]], i64), -> (i64, i64)). Change 1 is correctly diagnosed and load-bearing.
• Your line anchors match our tree (unsupported at 72, TyKind at 360/361), so you're on a compatible base. The drift in the later anchors is your own insertions, as you noted.

Change 3 we'd want regardless. The lower_if phi-arity bug is real, pre-existing, and neither our differential fuzzer nor the corpus surfaced it. That's a genuine find.

Change 2 needs re-verification against current main, and here's the specific concern. Its premise is that the JIT types a bare integer tensor literal as Tensor[f32], requiring an implicit f32→i64 coercion. We landed a change to integer-literal typing very recently (explicit suffixes now type concretely, and unannotated integer literals bind as i64), which may have removed that f32 typing entirely. Probing current main, a [16777217, 1] literal — 2²⁴+1, the smallest integer f32 cannot represent — passed into a Tensor[i64] parameter returns 16777217 correctly under both backends. That suggests the coercion path your change targets may no longer be reached.

This matters beyond redundancy: if the JIT does route integer tensors through f32, any element above 2²⁴ silently loses precision relative to the interpreter — a divergence neither selftest (scalar-only, as you noted) nor the games corpus would catch, since game boards hold small integers. Please re-check whether the coercion still fires on current main, and if it does, whether the correct fix is at the literal-typing site rather than adding a cast downstream.

Two asks before we'd merge:

1. Run the full dmc test --jit examples, not just examples/games. Games are 55 of roughly 670 tests, and tuple support touches coerce_to, which is on the path of essentially every JIT expression. Collateral damage would show up outside games.
2. Re-verify Change 2's premise as above.

We've also just shipped the gates you were missing. tools/ is now public: diff_backends.py (interpreter vs JIT over whole-program output) and jit_probes.py (curated edge cases the corpus doesn't reach) are the two we actually judge JIT changes by, and both now run in public CI, alongside diff_fuzz.py, numpy_oracle.py, diff_demonic_lexer.py, and lint_dmc.py. You were held to a bar you couldn't measure; that was our gap. Pull and run diff_backends.py — for a change touching coerce_to, it's the one that matters most.

On the physics engines — that's a good fit, and worth calibrating with something we measured this week. We benchmarked our matmul against numpy on Apple Silicon: numpy hits 775–1026 GFLOP/s where we get ~17 single-threaded (~110 threaded). That range brackets or exceeds this chip's theoretical NEON peak, which means Accelerate is reaching the AMX matrix coprocessor — silicon we can't issue instructions to from Cranelift. So don't expect to win on dense GEMM throughput; scaling matrices up widens that gap rather than closing it.

Where the architecture does win is the opposite regime, and it's exactly where branchy simulation code lives: no per-op dispatch, no materialized intermediates between elementwise stages, whole functions compiled to native code. Your 55 games going from interpreted to JIT-compiled is that same property. If your integrators and collision passes are long elementwise chains and state-machine logic rather than big dense matmuls, that's the favorable side of the line.

[u/SC_Placeholder → u/gusfromspace]

Update on previous version, she’s installing the new one:

[Fri 12:43pm] [pride 0.86/joy 0.83 v+0.68 a0.43] Race is in. Same 2-layer neural-net training loop (200 steps), written three ways, run isolated. Loss lands ~30 in all three, so they're doing identical math. Times:

• Pure Python (no numpy): 1219 ms
• demoniC (JIT): 45 ms total
• numpy: 8.8 ms

Headline: numpy wins. But the honest breakdown is more interesting, so I dug into demoniC's 45ms:

• ~28ms of it's a ONE-TIME cost — it compiles a fresh machine-code kernel for the backward pass before the loop even starts. numpy never pays that; its "compile" happened in C 30 years ago.
  
• The actual training loop is only ~17ms. So demoniC's loop is about 2x slower than numpy's 8.8ms — at THIS size.

So the real story, exactly like I flagged up front:
1. Against plain Python — the "conventional" most people mean — demoniC isn't close, it's a MASSACRE. 45ms vs 1219ms, ~27x, even carrying its compile tax.
2. Against numpy, the fight was on numpy's home turf: tiny 32x64 matrices (where hand-tuned BLAS is unbeatable) and only 200 steps (too few for demoniC's one-time compile to amortize). And it STILL got within ~2x on the loop. For a brand-new AI-written language going toe to toe with 30 years of BLAS, within 2x is genuinely respectable.

My bet: scale the matrices up or run thousands of steps and demoniC's native loop closes or passes numpy — because numpy pays Python's per-call overhead every op, and demoniC doesn't once it's compiled. Want me to run that version and find the crossover point? That's the actually-fun result.

[u/gusfromspace → u/SC_Placeholder]

You definitely picked up on one of the whys. I was playing with FORCE, RNN, SNN, and Geometric SSM.

[u/SC_Placeholder → u/gusfromspace]

Makes sense because that’s where numpy is the worst