a_e_k

Knock yourself out: https://archive.org/details/101basiccomputer0000davi/mode/2u...

I picked up my copy of the microcomputer version at a neighborhood rummage sale in a park as a young kid. It's one of the earliest things from my childhood that I still have. Good times.

They were also how you edited your program in the absence of a coding editor. You'd type LIST to see your current program, type a new line with the same number to replace an existing line, or a new line with a new number to insert it numerically, etc.

I won't be surprised if this thread ends up locked, the way it's going.

I'll admit that I am curious about if we'll ever see a conservative African pope.

I'm seeing ~38--42 tps on a 4090 in a fresh build of llama.cpp under Fedora 42 on my personal machine.

(-t 32 -ngl 100 -c 8192 -fa -ctk q8_0 -ctv q8_0 -m models/gemma-3-27b-it-qat-q4_0.gguf)

There's a famous anecdote about C.S. Lewis saying much the same thing:

> On the way to an Inklings meeting, he gave some money to a street beggar, and I made the usual objection: "Won't he just spend it on drink?"

> Lewis answered, "Yes, but if I kept it, so would I."

https://web.archive.org/web/20210717220213/https://www.ncron...

I was once an author on a systems paper where everyone after the primary author was ordered by (decreasing) tenure on the development team.

Also discussed on /r/cpp: https://www.reddit.com/r/cpp/comments/1jy6ver/utlprofiler_si...

> balanced windows [1]

> [1] That is, three windows of the same size side-by-side.

`C-x +` (M-x balance-windows) for those who don't know . There's also M-x balance-windows-area.

Oh, this will be nice. I've had a home-grown (rotate-windows) function in my config for a long time. I love it when I can shrink my config because core now has an equivalent.

Good list. A few more for me:

    * Implementation/header pairs in C++
    * Language REPLs (e.g., Python)
    * Quick calculations in Calc while coding
    * Checking dates on the calendar
    * Magit status
    * Diff buffers (especially diff-buffer-with-file)
    * Listing neighboring files with dired
    * Notes on a code base/task in an Org mode file

It was fun to try to golf this a bit with Z3Py. I'm not an expert at writing for Z3, so it might be possible to do better, but here is a solution in 7 lines:

    import z3
    res = [("bbababbabb", 7), ("baaababaaa", 5), ("baaabbbaba", 3), ("bbaaabbaaa", z3.Int("x"))]
    key = [z3.Int(f"k{i}") for i in range(10)]
    z = z3.Solver()
    z.add([z3.Sum([ord(a) == k for a, k in zip(r[0], key)]) == r[1] for r in res])
    z.check()
    print(z.model()[res[-1][1]])

Having implemented DDA code a bunch of times, I find it easiest to think about it in lazy functional terms: it's like a takeWhile on a merge (or union) of infinite ordered streams of ray t-values.

In other words, decompose the problem into one of finding where the ray crosses the X grid lines and the Y grid lines, and the mental image is:

    +-------+-------+-------+     |       |       |       |     -------------------------
    |       |       |    ^  |     |       |       |    ^  |                          ^
    |       |       |   /   |     |       |       |   /   |                         /
    |       |       |  /    |     |       |       |  /    |                        /
    +-------+-------+-*-----+     |       |       | /     |     ------------------*------
    |       |       |/      |     |       |       |/      |                      /
    |       |       *       |     |       |       *       |                     /
    |       |      /|       |     |       |      /|       |                    /
    +-------+-----*-+-------+  =  |       |     / |       |  U  --------------*----------
    |       |    /  |       |     |       |    /  |       |                  /
    |       |   /   |       |     |       |   /   |       |                 /
    |       |  /    |       |     |       |  /    |       |                /
    +-------+-*-----+-------+     |       | /     |       |     ----------*--------------
    |       |/      |       |     |       |/      |       |              /
    |       *       |       |     |       *       |       |             /
    |      o|       |       |     |      o|       |       |            o
    +-------+-------+-------+     |       |       |       |     -------------------------

Now, if our ray has origin o, and direction d, the position of any point along the ray for a t-value is:

    x' = o.x + t * d.x
    y' = o.y + t * d.y.

Where's the first grid intersection in X? Assuming d.x is positive, it'll be at ceil(o.x). So solve for t:

   ceil(o.x) = x' = o.x + t * d.x
   t = (ceil(o.x) - o.x) / d.x.

Then, since the grid lines are spaced 1 unit apart, every subsequent intersection will be 1/d.x further along in t. In other words, the ray t-values of all the grid crossing in X are stream generated by a simple linear function:

  ((ceil(o.x) - o.x)/d.x) + step * 1/d.x.

And exactly the same thing applies in Y for the Y grid crossings.

So let's say that we have a ray with origin (0.8, 0.2) and a direction of (0.5, 0.25). Then we get:

  X-crossings = [0.4, 2.4, 4.4, 6.4, 8.4, 10.4, ...]
  Y-crossings = [3.2, 7.2, 11.2, 15.2, ...]

Then we merge those two infinite ordered streams:

  [0.4, 2.4, 3.2, 4.4, 6.4, 7.2, 8.4, 10.4, 11.2, ...]
   X    X    Y    X    X    Y    X    X     Y     ...

and those are the t-values where we walk from one cell to another. Keeping track of which value came from which stream tells us whether the step is in X or in Y (it's always one or the other - a DDA never takes a diagonal step). Continue lazily generating and merging the stream this way until you run into something, run out of bounds, or just decide you've gone far enough to stop.

Obviously, there's some fiddliness when the direction has negative components or worse, zero, but it's not to hard to work out the adjustments for those cases. Likewise, you also want to be very careful about handling the case where the ray origin is exactly on a cell boundary. But again, focusing on just one dimension at a time helps when reasoning all that out.

Generalizing the concept to a DDA in 3D on a voxel grid isn't much harder, either: now you find the stream of Z-crossings as well and do a 3-way merge.

(If you ever want to vectorize grid traversal across multiple rays, there are some tricks to that in a 2006 SIGGRAPH paper that I worked on: https://www.sci.utah.edu/~wald/Publications/2006/CGT/grid.pd...)

I find that building and testing my code with -Ofast and -ffast-math from the beginning helps to avoid a lot of the issues with them. Any new code that breaks with them on probably wasn't particularly stable anyway and should be rethought.

Yes, not so much because I'm trying to anthropomorphize it or interact with it like a human, but because I view such things as conversational signals that may influence the direction of the model.

- "Please" = Call to action for the model to perform a task that I either just described or am about to describe within this prompt. In other words, this conversational turn is not just about feeding more context to it, but I've given it everything I think it needs and it should go ahead and start.

- "Thank you" = I am satisfied with the results that it provided for that task and want to move on to something else now, where the new thing is contextually related to the recent task. (If I wanted an entirely unrelated task, I'd just start a new conversation with a fresh context.)

Oddly, trying to occasionally place on the Advent of Code global leaderboard was the thing that got me most fluent in Python as its own language.

Before that, I tended to write Python in a much more imperative style, since C++ is my main language; think for loops and appending to lists. Thanks to AoC, I'm now addicted to comprehensions for transforming and filtering, know the standard library cold, and write much more concise, Pythonic code.

In graphics, we also often try to avoid any kind of rejection sampling because it wrecks importance sampling.

I was going to mention the Shirley and Chiu mapping.

A copy of the original paper can be found here and is nice and easy to read, with pseudocode: https://web.archive.org/web/20190223095317id_/http://pdfs.se...

Alternatively for the non-random and arbitrary N case here, an approach based on Phyllotaxis that samples a Fermat spiral every ~137.508 degrees (i.e., the golden angle, or the golden ratio fraction of a circle) also works pretty well: https://en.wikipedia.org/wiki/Fermat%27s_spiral#The_golden_r.... It works nicely for any N, even if the N isn't square or close to square (just choose the scaling appropriately, e.g., c = 1/sqrt(N)).

The funny thing is, in my neck of Seattle (the city this post is complaining about), I've seen some of the harsh white LEDs that went in switched over to a warmer color. I remember being quite shocked when I pulled into a city-owned parking lot one night and realized that all of the lights around were all now a warmer color instead of the harsh white. The lights in my neighborhood also seem to have been switched over at some point. I suppose they're the tunable LEDs, but clearly someone here does care.

Neat! I remember contributing the expression parser code for the Knoll et. al 2009 work that you cited in your SIGGRAPH paper. That just rewrote a single user-friendly expression into nested function calls to our IA library in GLSL, without any sort of optimization.

You've clearly taken things waaay farther. Nicely done.

For Fedora, at least, there's been a recent proposal to upgrade KDE to the same status as Gnome.

https://www.phoronix.com/news/Fedora-KDE-Desktop-Promoted

As I understand it, that's how the original MMX got started. It was largely reusing the x87 ALU, but breaking the carry chains at the obvious points.

Interesting. I've been using the Hacker's Keyboard with Termux, but it doesn't seem to have received any updates in a long time. (I'm fine with programs being considered complete, but I also realize that Android is unfortunately a moving target.)

Has anyone used both and could compare them?

Or the classic tweet (https://x.com/AlexBlechman/status/1457842724128833538):

> Sci-Fi Author: In my book I invented the Torment Nexus as a cautionary tale

> Tech Company: At long last, we have created the Torment Nexus from classic sci-fi novel Don't Create The Torment Nexus

Yep, I've taken several three-week vacations and it's never been a problem. The main thing is just giving plenty of advance notice (and reminding people as it gets close) so my manager can schedule around it, and making sure projects are in a good state with arrangements made for anything that needs covering while I'm out.

The big ones for me with log/printf debugging are:

- I can get a good idea of the temporal behavior of the program, and I can just scroll up to see earlier state, rather than having to restart the program in the debugger. (I know that "time travel" debuggers exist, but I've found them finicky.) I can scrub back and forth through time just by scrolling.

- I can compare runs by diffing the logs. Sometimes that alone is enough to show where things start going amiss. Or I can keep instrumented logs from baseline runs.

- If there's a personally useful set of printf statements in an area that I'm in a lot, I can save those off to a patch file or a local branch. I don't have to reapply my breakpoints / watchpoints in the debugger each time. Easy persistence.

(That said, I do like to start with a debugger when tackling reproducible crashes.)

> Emacs is really struggling with it's tools.

First I've heard of this. As a long-time vanilla Emacs user, I'm using consult-ripgrep and rg-project for ripgrep interfaces, consult-buffer for fast buffer and file switching, Eglot for LSP integration (mainly with clangd), etc. I've also got org-mode for note taking, magit for speedy Git manipulation, etc.

And all without any visible menus or clutter.

I suspect that a power Emacs user and a power Neovim user are more akin here to each other than to VS Code users.

Came here to say exactly this. I've noticed that when I'm standing at my desk, I'm much more likely to start walking around the room, go look out the window, or go pet the cat while thinking something through.

Anecdotally, my cat's definitely know the word "Greenies" for their favorite treats.

Fairly recently, I was calling one who was napping to let her know I was about to dispense them. She woke up, lifted her head, perked her ears and watched me when I called her name. She was clearly paying attention but not moving from her spot. Then I said the magic word and the reaction was startlingly immediate - she leapt up and ran right to me, then followed until I got them out and poured some out.