loxias

I would love, _love_ to know more about your data formats, your tools, what the JSON looks like, basically as much as you're willing to share. :)

For about a month now I've been working on a suite of tools for dealing with JSON specifically written for the imagined audience of "for people who like CLIs or TUIs and have to deal with PILES AND PILES of JSON and care deeply about performance".

For me, I've been writing them just because it's an "itch". I like writing high performance/efficient software, and there's a few gaps that it bugged me they existed, that I knew I could fill.

I'm having fun and will be happy when I finish, regardless, but it would be so cool if it happened to solve a problem for someone else.

These are SO, AMAZINGLY pretty! Are these blender renders? or...?

Firstly, at the $219 price point you can have my money already.

Beyond that, things that appeal to me are basically anything which increase the likelihood I can accomplish high dexterous fine motor control skills, for things like tinkering and DIY assembly. I think that would include extra wrist DOF and a longer-reach variant.

Integrated cameras are an interesting idea, but I'd like to be able to swap them out for my own.

My dream is to have some sort of multi-arm table at home. I imagine holding a circuit board, small component, soldering iron, and wire with four robotic arms I control with shaky hands from my laptop. :D

Try TDA ("mapper", or really, anything based on kernel density computed connectivity), it's a whole new world.

This ain't your parents' "factor analysis".

based

> "This Is How You Lose the Time War"

No other book captured the feelings of being 20-something and flirting like reading this. Reading it felt like being right back there again, with all the excitement and anxiety. Highly recommended to anyone.

Unsure how it connects to the notion of a brain filling in the blanks. I thought it was quite "filled in", but maybe my brain did it, and therefore I'm making your point for you :)

I look forward to reading this in closer detail, but it looks like they solve an inverse problem to recover a ground truth set of voxels (from a large set of 2d images with known camera parameters), which is underconstrained. Neat to me that it works w/o using dense optical flow to recover the structure -- I wouldn't have thought that would converge.

Love this a whole heck of a lot more than NeRF, or any other "lol lets just throw a huge network at it" approach.

Thanks for what you're doing. Of all the various companies and orgs posting chatter about deep learning, I've come to really appreciate your efforts (and Anthropic), because you're USING MATH. :)

I have some understanding of applied math, continuous and discrete, and while I don't keep up to date with developments in deep learning/AI in general, I always look forward to unsloth posts because they tend to center on achieving a desirable result thanks to proper application of good old fashioned "understanding the damn math and once you do, then doing the obvious". :)

Reminds me of learning about how to optimize twiddle factors in wring a performant FFT (more than divide-and-conquer, one also uses trig identities and some algebra to reduce the number of multiplies), or of learning of elliptic minimal Q-factors (EMQF) filters -- clever IIR filters that give a sharp frequency response using less than 50% (or is it 25% or more?) of the computation required traditionally by optimizing for *coefficients with lots of zeros in the base 2 representation*. And computers, it turns out, can multiply numbers by zero really fast. ;-)

The throughline to me is that if you pause and think deeply about "wait, what are we really doing here?" and look at the whole math stack, and think about what computers are good at, sometimes you can achieve great results.

Most people don't correctly use an em-dash differently than a hyphen. That jumps out to me. :)

Wow! This is really cool! Really really cool! I imagine some sort of use where it's even more collaborative and not just "unadorned turn-by-turn".

For example, maybe I'm taking notes involving words, simple math, and a diagram. Underline a key phrase and "the device" expands on the phrase in the margin. Maybe the device is diagramming, and I interrupt and correct it, crossing out some parts, and it understands and alters.

Sorry, I know this is vague, I don't know precisely what I mean, but I do think that the combination of text (via some sort of handwriting recognition), stroke gestures, and a small iconography language with things enabled by LLMs probably opens up all sorts of new user interaction paradigms that I (and others) might be too set in our ways to think of immediately.

I think there's a "mother of all demos" moment potentially coming soon with stuff like this, but I am NOT a UX designer and can't quite imagine it clearly enough. Maybe you can.

This is really, really cool and thanks for making it!!

We must think at least somewhat similarly, last few times I was apartment hunting I did the same, though I never polished it up like this (more plugging numbers into a spreadsheet).

Honestly the biggest thing this does for me is validate that the data APIs must exist for what I'd really want, which is write something to make much larger and more complex "programmatic" maps -- the list of places being generated by a more complex sequence of steps for instance, and the combining function for different criteria including nonlinearities.

Curious how you're computing the walking distances, I'm guessing this is combining some off the shelf API for it with another for the points of interest? Though it would be badass if you did it from scratch starting from just OSM. ;)

I found it was surprisingly easy to "populate with every instance of a given type". I've made a few maps based on grocery and transit where I did it by adding all >100 stores & stops.

> What I don't get isn't the benefits of BWT on its own. It's why BWT should add any additional benefit if you're already doing Huffman.

Ahhhh. Now we're on the same page. :) Seeing how it helps when combined is somewhat subtle/non-obvious. I believe it relates to BWT and Huffman both being approximations of something more optimal. The two transforms could also have different window sizes -- one rarely does BWT on a whole 1GB file -- which introduce inefficiencies. Huffman coding is also only optimal in the very large alphabet and very long data limits. As your data length and alphabet size decrease, it gets less optimal.

Put differently, "I think that's a wonderfully phrased question, this _is_ my specialization/subfield, and I'm gonna need to chew on it for a while."