archermarks

I love this article so much. Demystified so much about how watches work.

Even as far back as ancient Egypt [1]. And they had dentistry too [2]! Any time in history where they milled grains into flour with stone, you can see this pattern. In fact, it can be used to differentiate certain agricultural vs non-agricultural populations in the archaeological record [3].

[1]https://pubmed.ncbi.nlm.nih.gov/19396207/

[2]https://anatomypubs.onlinelibrary.wiley.com/doi/10.1002/ar.2...

[3]https://pubmed.ncbi.nlm.nih.gov/16353225/

Winner of the 2024 Ig Nobel prize in probability [1]. A nice read as well!

[1] https://improbable.com/ig/winners/#ig2024

This is super cool. As another commenter said, I'd like to see this for other natural dyes (onion skins, walnuts, etc).

Yes. You can add whatever passwords. It asks you for a URL but you can put anything in.

reddit's printsf subreddit is the best place to discuss sci fi and fantasy imho. Low spam rate, good, in-depth discussion, and obscure recommendations from people who genuinely love the genre and aren't judgy about it.

Pandoc! I write markdown and generate HTML pretty straightforwardly.

Agree. People act like peer review is this unshakeable tenant of the scientific method, when it only became widespread in the 70s and 80s. To my mind, papers written these days are usually a lot worse than those written before peer review, often due to the demands of that process (soften your language here, obscure your point there, cite thirty other papers unnecessarily just in case one of the authors is the reviewer).

Nice article, thanks for sharing!

Really nice article! I have some OpenGL familiarity and tried out Vulkan but bounced off of it due to all of the up-front complexity just getting something running. Might give it another shot now!

Yes.

https://youtu.be/jCg7Pda_3Gw?si=c9AuabaYp49Hduwr

Sometimes, the fact that one implementation includes it can make it actually more difficult to standardize, if there are some implementation details that are disagreeable (see GNU's nested functions)

Nice article, thanks for sharing! Been implementing my own string type for fun recently and this is a useful reference!

Surprisingly, there exist people doing GPU programming outside of ML. I work in high performance computing and lots of people write CUDA code.

contracts = "government is a customer." the government wants a job done and you (the contractor) are paid to do it.

grants depend. grants can be "government wants someone to develop a technology/engineering capability and is paying you to do it if you can show that you're the best candidate". definitely a subsidy but not necessarily a handout.

Knowing as many people in the robotics space as I do, I suspect the demo may not be completely "pre-baked" but it is almost certaintly highly selected. Often they'll try the demo many many times until they get a clean run-through without mistakes. The circumstances are also likely pretty idealized, like they pick objects and settings that they know it performs well in.

EmpLemon has a video about this. He argued Blair Witch had the highest multiple (~1200x)

https://youtu.be/PYmi559SpWI?si=_oTiHXTili5K6W5s

That's a neat method! I hadn't seen it before.

Yeah, looking at it again it's not as accessible as I remember. It's quite mathy, but well-written.

An epsilon-ball is just a "ball" (circle or sphere analogue of dimension n, where n is the number of inputs) of radius epsilon (some arbitrarily small number). So you're correct that it relates to the resolution at which we can be said to "know" the solution.

With simulated annealing, the cooling schedule dictates how and when the algorithm switches from exploration to exploitation. With a logarithmic cooling schedule, the cooling rate is 1 / log (1 + t), so the temperature approaches zero extremely slowly, and the algorithm basically never switches out of exploration mode. You're correct that this is basically a brute force search of the domain, and this is the implication of the theorem I mention above--ANY global optimizer reduces to brute force search in the worst case.

Actually, quite a few algorithms can provably find global optima. However, there's a property of such algorithms that makes them (often, but not always) impractical for many problems.

Any algorithm which can find a global optimum must necessarily sample its input space densely. That means that to be sure that we have the global optimum, we must evaluate the function within every epsilon-ball in our input space. If we didn't, then we could construct a function which was the same as some function we had found the optimum for everywhere except for in a single epsilon-ball, and which had a lower value than the minimum value in that ball. Then, our algorithm wouldn't find this new minimum and thus would not be a true global optimizer.

This property means we can't really provably obtain global optima without prohibitive numbers of function evaluations. However, for most "normal" functions, these algorithms typically work quite well and are commonly used in derivative-free black-box optimization. One famous and easy-to-understand example is the DIRECT algorithm. The paper describing this algorithm is quite well-written and easy to read, and well worth your time if you're interested in global optimizers.

I use Fortran for some research codes (I also use Julia and C++). The main advantage of Fortran, to me, is that it is very easy to write very fast code, and has very few foot-guns. The latter property also means it can be quite difficult to do non-numerical stuff, but that's a great trade-off if you're a physicist or engineer wanting to write simulations. The name comes from "Formula Translation" for a reason. Doing the kinds of multi-dimensional array manipulation and linear algebra you can do with out-of-the-box Fortran in C or C++ feels like torture.

I generally prefer Julia, as its a more general-purpose language, but there are parts of Fortran I like better than Julia, such as

- Fortran uses static typing and is statically-compiled

- It's a lot easier to write slow Julia code than I'd like, and you generally need to think more to make code fast than you do in Fortran.

However, I think Julia beats Fortran in most everything else. My main gripe with Fortran these days is 1) lack of a decent default package manager (FPM seems great, but most Fortran codes don't use it) and 2) slow evolution due to the conservative standards committee. I don't understand why we still can't have extremely basic generics in 2023, or a simple string type.

Yeah, "dense" kind of under-sells it. Given the distance to its host star, I would guess that this must be a gas giant core that had its outer envelope blown away? Otherwise this seems hard to fit into our typical models of planet formation

This is an awesome way to widen the reach of their research. I did a similar video for some of my PhD research in spacecraft propulsion and plan to make some videos for future papers I publish.

I love this? I'm not sure if it's ironic, unironic or what but I'm digging it.

I use fortran in my day to day work and most of my work has been modernizing and refactoring an oldish code. Its amazing how nice it can be to work in once you've removed and reorganized the legacy cruft.

> They do no work, take all the profit, and obstruct research and the spread of knowledge. Those are some of the worst scums of capitalism.

Amen. Pure rent seeking parasites.

That's a cool idea! That way if you miss the leading indent you can still tell a block of text is indented.

This movie is one of my favorites. It's absolutely hilarious and so so 90s in the best way.

In this case, we know they would be able to interact via electromagnetic waves. So we would not need to invoke quantum wavefunctions in order to get the right behavior. The tricky bit is predicting the type of wave, their growth, and their propagation characteristics.

I still don't know if i really follow here. We are not detonating anything, and there is no precise time required. The confinement is magnetic in nature and not really a property of the gas species.