amitp
Joined 15 years ago
Karma
934
Submissions
206
Member since
Jan 14
Recent submissions
Comment · 5 days ago
And with llm-buddy [1] everything I type in emacs gets sent to an LLM, which makes it even more valuable to do more things in emacs.
Comment · 5 days ago
:-)
Tangent: SRE was very color-heavy and that led to some long ANSI sequences. From the recently decompiled source [1] you can see that I tried to pick shorter ANSI sequences when I could. In particular, going from color 0x0* to 0x1* we could save 1 byte, and going back to the default white on black we could save between 1 and 4 bytes. But if you're bandwidth limited there's also an option to turn off color entirely.
[1] https://github.com/joeshaw/sre-reconstructed/blob/main/src/s...
Comment · 1 month ago
I think it'd be reasonable to keep uber, but I had dropped it because it wasn't in /usr/share/dict/words on Linux or Mac. That was a quick&dirty way to filter out proper names, but it misses some other words too.
Comment · 1 month ago
I added the word list to the main article. The rule is for two words, ubiquitous and ubiquity, so maybe the rule should be tightened to word.startswith("ubiqu").
Uber and Ubuntu are not in my word list (which attempts to exclude proper nouns), but maybe I should add uber, uberant, uberous, uberously, uberousness, uberty, uberties.
I had a self-imposed time limit of 1 day for this side quest, but there are lots of ideas in the comments here so someday I may come back to this project and give it another day.
Comment · 1 month ago
*hones
Comment · 1 month ago
Good catch — "homes" wasn't in my /usr/share/dict/words for some reason so I missed this case!
Comment · 1 month ago
That is my favorite podcast of all time!
Comment · 2 months ago
Bookmarked! I love the interactive diagrams! I love that you have a touch-point larger than the drag handle. And I'm impressed that the label placement takes care to avoid the axes. Some feedback:
You have vector s in blue, and then vector u in teal, and then vector v in orange.
In the diagram, it's "Subject", "First Reflector", "Second Reflector". I think it'd be better if these labels were "Subject s", "First Reflector u", "Second Reflector v" so that we can match up the text to the diagram even without color.
Later you have "The pair of vector u and v is called a rotor". But these colors do not match the earlier colors, and it makes it hard to connect to the diagram.
In the 3D diagram, I think it would be better if you used the same color scheme as for the 2D diagram. Same for the circular reflection diagram.
Suggested colors:
- subject s - orange in every diagram (currently blue, blue, blue)
- first reflector - teal in every diagram (currently teal, magenta, pink)
- second reflector - blue in every diagram (currently orange, teal, orange)
This makes the rotor colors more similar to each other than to the subject.
Comment · 2 months ago
Thanks — yes, I'm still struggling to find a good way to explain the colors. The landmark is green. The blue tiles are the savings — the difference between using the landmark and not using it. I'll work on a different wording or maybe a visualization.
Changing the graph is another optimization that's commonly used. A graph of rooms is far smaller than a graph of tiles, and you can precompute paths on the small graph. The landmark heuristic can work on that graph too, although with the small examples on the page you probably wouldn't need to.
Comment · 2 months ago
Yes, it's a bit weird! There are also optimizations that do what you describe, with landmarks along the way, but at least at the time I learned about it, road map pathfinding was using landmarks behind the target.
Comment · 2 months ago
Good catch. I was thinking people would read that after they have moved the green L but I should handle both before and after moving L.
Comment · 2 months ago
The landmark data can be calculated in a background thread. For DF I imagine you'd have a background thread running all the time, updating one landmark every so often. But what happens if you look for a path before the landmark data is updated? I haven't tested this yet but I believe this is how it'd work:
1. If the cost of a tile decreases, the precalculated heuristic will be too high, so A* might find a non-shortest but ok path. In game, you can think of the dorf as following the path they already know about, because they don't yet know that there's a shorter way.
2. If the cost of a tile increases, the precalculated heuristic will be too low, so A* will find the optimal path but it will take a little bit longer (still not as long as if we weren't using this heuristic). In game, you can think of the dorf as following the path they already know about, but running into a wall, so then they find a path around it.
Comment · 6 months ago
I found https://www.youtube.com/watch?v=a_rAXF_btvE to be more balanced than the LTT video, but I think it mostly depends on your expectations of the cameras. The videos themselves are stored locally, not in the cloud. But if you have thumbnails turned on in the notifications, then the thumbnails have to be stored somewhere temporarily (I think this is an Apple/Google requirement), and they're being stored on a cloud server rather than in your home network (which would require opening up a port).
Comment · 6 months ago
Slug preserves the vector shapes. MSDF first converts to a texture, which can lose small details. How much depends on the size of your texture and the complexity of the font. I expect MSDF will never look better than Slug.
However, MSDF can handle lots of distance-based effects (glow, shadow, outline, gradient, etc.)[1], and I don't think Slug does that. And MSDF is constant time whereas (I think) Slug is going to vary depending on the complexity of the font.
The Slug paper [2] says:
All of the techniques that store data in a texture atlas are inherently using a discrete
sampling of what is actually an infinitely precise description of a glyph outline. This
inescapably leads to limitations that can be mitigated by increasing the resolution of
the texture atlas, but that can never be completely removed. For applications that
need to render a wide range of characters at potentially large font sizes, a texture atlas
capable of producing glyphs at an acceptable level of quality may have prohibitively
large storage requirements.
Comment · 8 months ago
Thanks!
twitter:@redblobgames