tomtom1337

Could you explain more what you mean? Other than certain holidays perhaps causing a higher chance of alone time for future mom and dad, I don’t see what you mean, and I don’t understand your last paragraph.

That’s an excellent example of Goodhart’s law!

"When a measure becomes a target, it ceases to be a good measure".

Thank you for sharing! I am convinced! Completely agree that this is a problem!

I guess the unspoken assumption Babbage makes here is «if I put only the wrong figures into the machine». Then it is completely unreasonable to expect correct output. In ML context an LLM has been trained on much data, some «wrong» and some (hopefully more) «correct», which is why asking something incorrectly can still give you the correct answer.

I updated the benchmark [1] that I wrote to someone who responded to you to include a even/odd filter and take the minimum time of 100 runs. Python 3.13 is much faster for small lists, and a tiny bit faster for larger lists. The times are the time taken for iterating per entry in the list comprehension.

Running on Python 3.12.7 (main, Oct 2 2024, 15:45:55) [Clang 18.1.8 ] 16.69ns on N=100 18.84ns on N=1_000 15.88ns on N=10_000 14.26ns on N=100_000 14.70ns on N=1_000_000

Running on Python 3.13.0 (main, Oct 16 2024, 08:05:40) [Clang 18.1.8 ] 9.54ns on N=100 17.88ns on N=1_000 15.81ns on N=10_000 14.14ns on N=100_000 14.46ns on N=1_000_000

[1] https://gist.github.com/thomasaarholt/2e4d42cbf3f0de60c811bb...

Great minds think alike. Here's one I just cooked up. Python 3.13 is faster, at least for the simplest possible list comprehension with no filters. N is the length of the list comprehension. Repeated 100 times for each test and showing the average. Run on a MacBook Air M3.

https://gist.github.com/thomasaarholt/2e4d42cbf3f0de60c811bb...

  Running on Python 3.12.7 (main, Oct  2 2024, 15:45:55) [Clang 18.1.8 ]
  11.32ns on N=100
  9.42ns on N=1000
  7.32ns on N=10000
  5.23ns on N=100000
  5.87ns on N=1000000
  
  Running on Python 3.13.0 (main, Oct 16 2024, 08:05:40) [Clang 18.1.8 ]
  7.30ns on N=100
  5.91ns on N=1000
  5.09ns on N=10000
  4.31ns on N=100000
  5.89ns on N=1000000

The animated ripple across the «what’s new» button is infuriating. It keeps drawing my attention from reading what this is.

Well, one single long exposure would literally generate a regular sized image. Though I do guess they’ll be doing multiple exposures if only to avoid saturating their dynamic range.

Does anyone know what a typical number of acquired frames is for a space telescope?

The most common solution is to frequently retrain on the latest data. A forecasting model might retrain every week, including the last weeks data, and might even drop older data, for instance training data older than a year.

It's best to transform your target variables, like "number of orders", to "number of orders per customer per day" or something like that. And then in your pipeline, you feed the latest estimate on your number of customers (e.g. average of the last two weeks). That's way more robust over time.

I haven't read the text, but data drift refers to how, after deploying a machine learning model, the input data changes over time to something that wasn't tested on. For instance, let's say you create a gradient boosting forecasting model that does a great job at predicting tomorrow's earnings. At the time of training, the earnings might be in the $1000 per day range. But a year later, the earnings might be in the $100k range. The model has never seen numbers this high before, so it doesn't know how to handle them well. That is data drift.

Can you explain what you mean by this?

As an aside to the topic, that's not quite how the maths would work. If the panels were 100% more efficient, you wouldn't need 100% less of them

If the panels were 20% more efficient, you'd want 1 -1/1.20 = 16.7% less of them.

Oh my god! Thank you for reminding me of bzflag! Those are great memories!

Lovely explanation! Thank you! It is simultaneously crazy that neutrinos can pass through so much matter unhindered, yet intuitive that when something is so small and can only interact with such a small fraction of the volume it is passing through - it can indeed pass unhindered.

This was a wonderful little read, thank you!

Agreed! "What would happen if we were off by some tiny fraction" is a really interesting question to me!

Please do share what you learn! I'm considering switching from mac to Linux, and wezterm is my daily driver.

I would appreciate that! Please do!

This sounds interesting! Have you published it yet?

Is the idea here to accurately track the acceleration that the sensor is undergoing? So, if you started at a known location with velocity=0 and integrate the acceleration data wrt time twice, you get the relative change in position and can thus know your new location?

Very interesting! I've found a lot of numpy indexing confusing, so it's very nice to see some effort to clean it up!

This is a very useful methodology. There's a similar blog post called "parse, don't validate" [1] which is very good.

[1] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Wow! I'd not noticed this before! Thanks for sharing!

This is great! One request would be for the smoothing when zoomed out to not generate square pixels.

Example: https://imgur.com/a/lRrHHTJ

Helix is another one, that tries to improve upon the kakoune model.

I have not used spark, but I have written a lot of sql, polars and pandas. I think much more in terms of sql when I write polars than pandas. Do you have any examples of what you are referring to?

Fun idea. Here are some suggestions:

- You don't need it to confirm the cell click. That takes away from the enjoyment. Noone knows if "cell 74" is the one you meant to click or one next to it.

- don't show a popup after I click the spot. The game is quite intuitive when you see the number in the cell.

- don't start the timer until I click away the instructions.

- maybe add a gradient color from red to green depending on how close I am?

- another mode could be to include more than one spot. Then have the number only show the closest one.

I'm sure you've got some cool stuff here, but until you update your readme with at minimum one full, self contained working example, no-one is going to try this.

You should also turn your readme into a markdown file and incorporate the HOWTO into it. It'll make it appear a lot friendlier.

Still is, I think, with the Airpods. Perhaps not quite in the same way, and more of a status symbol than a fashion statement, though.

Likewise, thank you for defining it! I would have assumed it was some sort of technical language and not bothered to look it up!