Now if I can just use SIMD directly from Python without calling out to another language.

Hi Austin! Was just checking your blog and the vowels detection post (< https://austinhenley.com/blog/vowels.html>).

What exactly do you mean by “use SIMD directly without calling out to another language”?

In some way Assembly will probably anyways be another language… but that’s a technicality.

I guess the spectrum of SIMD-related work in relation to Python is quite broad. There are projects like PeachPy, to help one write x86 Asm in Python, new Python’esque languages like Mojo, or SIMD libraries with thin CPython bindings. Do you mean one of those?

PS: I’m in the last camp. And in case you are focused on ASCII, for vowel search, have you tried StringZilla’s `find_first_of` (< https://github.com/ashvardanian/StringZilla/blob/960967d78c7...>)? I think it should perform well ;)

why would you want to? if you are performance bound with Python code, you can pick up a 20-50x performance improvement by switching language.

Right, but if there's only a small portion of my code that does string search and it's a hot path, it would still be much much much more convenient to access SIMD-based string search code direct from Python rather than writing the code (LLM or not) in another language and then construct bindings (LLM or not).

2 problems.

1. Python's data types are all bad for performance

2. once you optimize once part, a new part will be the bottleneck

You can use cython and call C SIMD code from it.

Try Nim. It's pretty easy to get the hang of it for simple things, and you can make a python module too.

We are hiring.

Very nice find (pun intended). I added an update at the end with your solution and a link to this comment.

YouTuber or move to the mountains.

I think it is time * (votes+comments).

In practice, if it gets any real amount of votes or comments, you have to wait a year to repost. If it doesn't get any attention, it can be reposted quickly (though I think it should be a day later).

I spent nearly a week of my Microsoft internship in 2016 adding support for Source Depot to the automated code reviewer that I was building (https://austinhenley.com/blog/featurestheywanted.html) despite having no idea what Source Depot was!

Quite a few devs were still using it even then. I wonder if everything has been migrated to git yet.

Naah still a lot of stuff works on sd !! Those sd commands and setting up sd gives me chills !!

I miss CodeFlow everyday. It was such a great tool to use.

CodeFlow lives on and is still held in high regard. It's even made it's way to support the github repos, not just git. https://chromewebstore.google.com/detail/codeflow/aphnoipoco...

Still buried as internal only though.

Most of the day to day is in git, now.

Writing out hundreds of lines of code is not what I meant by proactive tools…

Where are the proactive coding tools? https://austinhenley.com/blog/proactiveai.html

It was probably auto flagged as dupe because the original was discussed recently: https://news.ycombinator.com/item?id=43957010

Thanks! We missed that. I've pinned a link to the other thread to the top now.

Discussed heavily 25 days ago: https://news.ycombinator.com/item?id=43957010

It's also not nearly as good as Eric Gilliam's "How did places like Bell Labs know how to ask the right questions?" https://www.freaktakes.com/p/how-did-places-like-bell-labs-k... , posted here a few months ago https://news.ycombinator.com/item?id=43295865 . That could almost have been written as a rebuttal to TFA's storytelling about unlimited researcher freedom at Bell Labs, though in fact it predates TFA by a couple of years.

Good thinking. I discuss population density, cities near borders, and narrow borders in the last section.

Another possible suggestion. Maybe choose random points that are within a set radius of points chosen along the borders? So perhaps choose first a random selection of points on the border, then choose random points within a circle (or perhaps just a square with a set delta in the lat/long) that are "nearby to the border" - then measure your error rates for those points at various boundary simplification tolerances? That'd remove the "middle of the state" random points where the border tolerance inevitable makes no difference.

As a native Philadelphian, I immediately see why you need a good resolution here - at 0.1 degrees resolution you very well could have assigned my birthplace to New Jersey. If I'm not mistaken New York and Philadelphia are the largest cities where you might have a problem. Chicago's on a state line but the Illinois-Indiana border is straight.

I wonder if it’s actually straight though? In the chart on the page, Colorado is described as having 7000-something vertices, where I would have expected it to have … 4.

There's the congresionally approved boundary. Then there's the surveyed boundary. Wherein a team of people goes out and hammers survey marks and tags into the earth or creates man made monuments when that is not possible.