3. TinyType

It's just type hints for tensors that specify shape. When you see:

def ones(i: int) -> TT[["i"]]:

This says "return a 1D tensor of length i". The test framework uses these hints to generate random test data of the right shapes.

4. ones_spec vs ones

• ones_spec = the specification (what the correct answer should be, written with loops)
• ones = your solution (what you need to implement using broadcasting)

You write ones. The test compares your output against what ones_spec produces.

5. Sample puzzles

They're examples showing how the puzzle format works. You can attempt them for practice, but the main puzzles are in the notebook (puzzles.ipynb). The samples just demonstrate more complex puzzle structures.

Any of these need more clarification before you dive in?

The constraint_set function is provided infrastructure, not part of your solution.

It's used by the test framework to adjust the randomly generated test data so it makes sense for that particular puzzle. For example, ensuring a "length" parameter doesn't exceed the array size.

You only need to fill in the function body that raises NotImplementedError. Everything else is already set up for you.

This adds the current directory (.) to Python's module search path, so you can import from files in the same folder (like lib.py or solutions.py from the tinygrad puzzles repo). Some environments don't include the current directory by default.

It's about making the format consistent for the drawing function.

• 2D tensor .tolist() → [[1,2], [3,4]] (already a list of rows)
• 1D tensor .tolist() → [0,1,2] (just a flat list)

By wrapping the 1D case in [...], it becomes [[0,1,2]] — a single row. Now the drawing code can always iterate over "rows" the same way, regardless of input dimension.

The drawing function renders grids with rows and columns. A 2D tensor naturally has rows. A 1D tensor is just one row, but .tolist() gives a flat list — the extra [...] wrapper tells the drawing code "this is one row" so it renders consistently as a single-row grid.

Exactly. .tolist() just converts the tensor to native Python structure directly:

• 1D tensor [1,2,3] → flat list [1,2,3]
• 2D tensor [[1,2],[3,4]] → nested list [[1,2],[3,4]]

It's not "removing" nesting — a 1D tensor simply doesn't have a row dimension to begin with. The extra [...] wrapper adds that row dimension artificially for display purposes.

No need to be embarrassed! Let me show you:

t1 = Tensor([1, 2, 3])           # 1D, shape (3,)
t2 = Tensor([[1, 2, 3]])         # 2D, shape (1, 3)

print(t1.tolist())  # [1, 2, 3]
print(t2.tolist())  # [[1, 2, 3]]

Same numbers, but t1 has no "row" concept — it's just 3 elements. t2 explicitly has 1 row containing 3 elements.

Want to run this yourself and see?

Looking at _draw_example, here's the high-level flow:

1. Extract keys (like "input", "output") from the data
2. Build columns — for each key, create a column with:
   • A text label at the top
   • Then _draw_matrix for each example's values
3. Arrange into a grid with _grid(cols)
4. Add a title on top
5. Wrap in a white rectangle for the background

The chalk library uses a compositional approach:

• / stacks things vertically
• + overlays things
• vstrut(0.5) adds vertical spacing

Would you like me to dig into any specific part — like how _draw_matrix renders the cells, or how the grid layout works?

Looking at the _draw_example function, I can see it calls set_svg_height(300) at the end. There are a couple of options:

1. After calling draw_examples, you can call set_svg_height() with a smaller value (like 100 or 150) to resize the output before it renders.

2. Modify the lib.py file to use a smaller default height.

Which approach would you prefer? If you want the quick fix, try adding this after your draw_examples call:

from chalk import set_svg_height
set_svg_height(100)

Does that help, or would you like to dig into other ways to control the sizing?

Good catch! Yes, the original had:

set_svg_height(50 * env.height)
set_svg_height(300)  # This immediately overwrites the line above!

The second call just throws away the dynamic calculation. Jeremy's fix removes that and uses a smaller multiplier (25 instead of 50) so the output scales with content but stays compact.

The key is an empty string "". Looking at the call:

[{"": arange(i)} for i in [5, 3, 9]]

It's empty because arange only has one output and no inputs to display. The draw_examples function uses dict keys as column headers above each example. Since there's nothing meaningful to label (it's just showing the output), an empty string means no label appears above the arrays — which is exactly what we see in the image.

If you had a function with inputs and outputs, you'd use descriptive keys like {"a": input_tensor, "out": output_tensor} to label each column.

You're right that there's an integer input (i). The distinction is:

• arange(5) takes an integer 5 — a Python int, not a tensor
• It returns a tensor [0,1,2,3,4]

A 1D tensor of length 1 (like Tensor([5])) is different from a plain Python integer 5. The puzzles framework treats integers as configuration parameters (sizes, counts) rather than tensor data to visualize.

You could wrap the input as a tensor if you wanted to display it — that's what the earlier example did with {"input": Tensor([i]), "output": arange(i)}. But for arange, the input is really just a size, not tensor data you're operating on.

Sure! Let's break it down:

1. @patch from fastcore lets you add methods to existing classes without modifying the original class definition

2. _repr_markdown_ is a special method that Jupyter/SolveIt looks for when displaying objects — if it exists, that method's output is used for rendering

3. self:Tensor in the function signature tells @patch which class to attach this method to

So this line:

def _repr_markdown_(self:Tensor): return f"```\n{self.numpy()}\n```"

Says: "When displaying a Tensor as markdown, convert it to a numpy array and wrap it in a code fence."

Before the patch, tensors showed that ugly <Tensor <UOp CPU...> representation. After, they show the actual values.

Does that make sense? Want me to clarify any part?

Exactly. Tinygrad tensors don't have a nice built-in way to show their values as a string — they show that verbose internal representation instead. NumPy arrays, on the other hand, have a clean __repr__ that displays the actual numbers. So .numpy() is just a convenient way to get a readable output.

Correct! print() calls __str__(), which now converts the tensor to a Python list via .tolist(), then converts that list to a string. Same idea as the markdown patch, just using a different conversion path.

Try this: add a method called describe to the Tensor class that returns a string like "Tensor with 5 elements" (using the tensor's shape to get the count).

Hint: self.shape gives you a tuple like (5,) for a 1D tensor.

Perfect! You got it. Now you know how to monkey-patch methods onto existing classes using @patch. Handy trick for improving ergonomics when exploring libraries.

Ready to continue with the tensor puzzles?