An interesting variant of space-filling curves + dimensionality reduction is Geohash (https://en.wikipedia.org/wiki/Geohash, http://geohash.org/) which takes a lon/lat and uses a Z-curve approach to produce a hash such as `u4pruydqqvj` representing the location. This hash value is basically "how far along the space-filling curve is the lon/lat located". You're reducing two dimensions (lon/lat) into one dimension (how far along the space-filling curve).
There's a unique side-effect to Geohashes in that the value (`u4pruydqqvj`) can have it's end "lopped off" (i.e. cut down to `u4pru`) and it still represents a less precise, but generally accurate representation of the original lon/lat in most cases (when the curve isn't near the edge of the 2d map!). This allows you to index locations (lat/lon) using a string ('u4pru') which opens you up to doing b-tree, range queries, etc. in traditional database, with one field.
Just a rad math quirk! I'm not an expert, and it's a very dense book, but if someone really wants to get into this kind of stuff the "Bible" is "Foundations of Multidimensional and Metric Data Structures" by Hanan Samet.
> [I]t's a very dense book, but if someone really wants to get into this kind of stuff the "Bible" is "Foundations of Multidimensional and Metric Data Structures" by Hanan Samet.
You're not Kidding! 1022 pages, with a TOC that nests 4 layers deep. In particular, section 2.1.1.2 "Ordering Space" covers space-filling curves, and true to your description it covers every point brought up in the comments so far:
- Peano-Hilbert curve of OP
- Z-order curve mentioned
- "Reverse locality" issues
- Performance considerations of the mapping function
The thing about SFC addressing is that two places near each other always share a prefix, and the closer they are, the longer the common prefix. It's sort of like Gray coding. Quadtree addressing, for example, also has the property that you mentioned (as do, of course, normal lat/long coordinates!) but two adjacent locations may not have similar addresses at all if they happen to straddle a subdivision boundary. (Again, compare to "normal" numbers where, say, |2000-1999| = 1 but there's no common prefix at all!)
The same happens, in fact, for space-filling curves. Sure, in _most_ of the area covered by the curve, closeness of points means closeness on the curve. But in this Hilbert curve:
Consider the two points on the curve straddling the middle of the top edge of the square. They are very close together, but their 1D addresses on the curve are very far apart (one close-ish to the beginning, and one close-ish to the end)!
The boustrophedonic version of Rosenberg-Strong function is my favorite because it doesn't have any such jumps and has better locality preserving qualities than most alternatives.
I keep trying VS Code, but I hate how when I split the screen three wide ("splits") it wants to open "editors" in each of the columns, even if it's the same file. I want a "buffer" like Emacs has that can be called up into any of the "splits" without reopening the file.
I disable the tabs display, but when I visit a file in each of the three columns (i.e. what in Emacs would be calling a buffer into a window) I end up with the same file open three different times, once for each split. Then the fast switcher just gets full of dupes. BLAH!
I really wish VS Code used the Emacs model of completely disjoined (a) buffers, (b) windows, (c) frames, but instead there's a hierarchical approach of Splits -> Editors.
I've dug into VS Code issues about this, and it seems the hierarchy between Splits -> Editors is a strong parent-child relationship embedded deeply within VS Code's model and is unlikely to change.
While Emacs is opinionated in its own way, it is extremely configurable, programmable, modifiable, customizable to ones needs. I guess it will take a long long time, until vscode is as modifiable as Emacs, if ever. And maybe that is not vscode's goal anyway.
VS Code's goal is to get the low-effort 30% of devs who want something that will just work right out of the box, while providing enough functionality/customization to attract a significant fraction of the remaining 70%. And given that, it's pretty good.
But I'm skeptical it will ever be as good for someone who does want to make the investment in something like Emacs.
This is my final quibble with VSCode as well - except I'm coming from Vim. I've hunted high and low through the settings - if anyone from the VSCode team is reading this, there's not another feature that's more vital to match vim/Emacs utility!
We're using WorkOS to build Directory/SCIM and are very happy with it. They have a really good API for syncing enterprise directories (G Suite, Okta, SCIM, Azuer, etc.) and webhooks to get changes.
It's easy enough to use even for internal applications, but we're using it to integrate customer directories with our product.
We're also using it to do SSO for our product. It's much easier than trying to integrate with each of these systems.
Hey, I just wanted to say this is awesome and if you need somebody to help test it I'd love to help.
I'm a software engineer, but also a big guitarist. The WaveNet stuff is really interesting, but I'm not a DSP/ML expert. I could help you:
* Model a Dr. Z Maz 38 MkII, 5w Fender Tweed Champ, Ampeg SCR-DI preamp/DI
* Provide raw samples of: Gibson Les Paul 1958 Reissue (R8), Fender Telecaster (1955 type partscaster), Fender Stratocaster (1962 "thin skin" reissue), Gibson 1963 SG Junior Reissue, Fender 1958 Precision Bass Reissue, Taylor 814ce acoustic guitar
* Get the code installed on my local, test whatever you need help testing, etc.
* Testing and feedback on the real-time plugin i.e. using a VST/AU in Logic, testing latency, testing sound against in-room amp sound, etc.
I'd also be interested in figuring out how to get the real-time plugin you're developing into a pedal enclosure. I have a friend who is a top notch silicon valley hardware/power engineer, and we've been toying with the Strymon Iridium, Impulse Responses, analog pedal building, etc. It'd be interesting to use some guerrilla marketing, sell a few pedals on The Gear Page, and see what people think.
benstandefer (at) <google's email service> (dot) com
Command E is a blazing-fast, secure way to instantly find anything in your cloud or on your computer via a Spotlight-like search and command interface on top of your data. It's basically a CLI for business users, built on top of their cloud data, inspired by the "fuzzy finder" search boxes in IDEs (i.e. Command-T plugin in vi, Helm plugin in Emacs, ⌘T in Atom, ⌘P in VSCode, etc.). It’s ridiculously fast - searches return in <10ms and we don’t warehouse your data - it stays on your own machine in an encrypted database.
We're now a venture-backed startup with a really strong team working on this every day, but I originally started building it after seeing information and data scattered across 20+ clouds even amongst a small team at my last job. I saw how Slack had applied a lot of polish on top of IRC and how APIs were reaching a sweet spot of standardization and maturation and decided the time was right to build something like this for other knowledge workers (and to bring the search pattern in our IDEs to all the other places we spend time as engineers).
We have 30+ integrations now, and I use it everyday to:
* Quickly jump to our PRs in GitHub
* Get into Zoom meetings with 2 clicks rather than digging into calendar events for the meeting link.
* Instantly get back to Google Docs and Clubhouse tickets (we also support Jira, Trello, and Asana along with most of the tools your product team lives out of)
The product is free and I'd love any feedback - you can download the app here: https://getcommande.com
1. Yes, there is a Slack integration. You can search for channels (#general) or DMs (@ben) and hitting Enter switches you to the Slack app and jumps straight to that channel. Kind of like Slack's Cmd-K, but computer-wide. Over time, the app tracks internally which results you're launching frequently, so jumping back to a certain channel should be 2-3 keystrokes.
2. We'll have a pro tier and team pricing in time - rest assured this isn't a data aggregation or marketing data play. Your cloud data never leaves your laptop. All the indexing is local in an encrypted index. We want to eventually charge a reasonable price for pro users or enterprise/team use cases, similar to GitHub, Dropbox, models etc.
reply