Recently I had fun reimplementing an old (but still usable!) code for accelerator optics. It involved transfer matrices for a 6D phase space to second order. Most of the FORTRAN77 source code was just pages and pages of hand-differentiated 6x6x6 matrices (with quite non-trivial elements) and the plumbing to painstakingly propagate those jacobians around for fitting... all replaced with a single, magic, call to jax.grad(). Felt like cheating!

I'm also super interested in its application to modelling, e.g. projects like https://github.com/deepmodeling/jax-fem -- particularly for chaining different sorts of simulations and analysis together and getting gradients through the lot. Also quite magic!

- someone who bought an investment property, which then appreciated, and then they wanted to take out a larger mortgage against the appreciated value to leverage it into buying another property.

- Someone borrowing against stock to avoid realising gains by selling it

That seems… reasonable to me?

For example: https://www.owhsp.qld.gov.au/court-report/fines-imposed-fail...

""" 1. Explore Government and Community Meal Programs (Often Low-Cost or Free) Many programs provide balanced, home-delivered meals designed for seniors, emphasizing nutrition over processed frozen dinners. These are ideal for someone on a fixed income who doesn't cook. """

Specifically, it recommended Meals on Wheels, the Commodity Supplemental Food Program (CSFP), Local senior food pantries or boxes through Feeding America food banks, and Medicare Advantage or Medicaid benefits.

To my obvious follow-up question, Grok replied "Yes, several of these programs have faced proposed cuts, eliminations, or other pressures during the current Trump administration"

Copilot button on my email inbox? I try "Find me emails about suchandsuch", and get the response "I don’t have direct access to your email account. If you’re using Outlook (desktop, web, or mobile), here are quick ways to find all emails related to...". Great, so it doesn't even know what program it's runnning in, let alone having any ability to do stuff in there! Sigh.

https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2019GL08...

"Retrospectively comparing future model projections to observations provides a robust and independent test of model skill. Here we analyze the performance of climate models published between 1970 and 2007 in projecting future global mean surface temperature (GMST) changes..."

https://www.youtube.com/watch?v=6Js8erWbsDQ

It's small and kind of underpowered, but not useless! The central idea is to 3D print shells that hold metal parts and are then filled with concrete for rigidity and mass. Quite clever, I think.

[1] https://github.com/python-trio/trio

https://github.com/tobinjones/uvkernel

It’s a pretty minimal wrapper around “uv” and “iPython” to provide the functionality from the article, but for Jupyter notebooks. It’s similar to other projects, but I think my implementation is the least intrusive and a good “citizen” of the Jupyter ecosystem.

There’s also this work-in-progress:

https://github.com/tobinjones/pep723widget

Which provides a companion Jupyter plugin to manage the embedded script dependencies of noteboooks with a UI. Warning — this one is partially vibe-coded and very early days.

It comes down to - what's the point of this? If it's to prove theorems to a computer then it's obviously the wrong approach. If it's to explain concepts to humans then it's _also_ the wrong approach. It's not true in any useful way that one can learn something by just starting at a random "node" and then "tree shaking" some big "knowledge graph" and just learning the specific edges that remain.

That said, no hate for this kind of tool! Interlinked knowledge is obviously great and useful, it's the emphasis on designing a rigid ontology that makes me raise an eyebrow.

Could be fantastic for my use-case. We have a large repo of notebooks that are generally write-once, sometimes-re-run. Having a separate repo/venv/kernel per notebook would be a big overhead, so I currently just try to do a kind of semantic versioning where I make a new kernel on something like a 6-month cadence and try to keep breaking dependency changes to a minimum in that window. I can then keep around the old kernels for running old notebooks that depend on them. This is not at all an ideal state.

Thanks for sharing!

As for the drawings themselves, I have found them pretty unreliable at reading even quite simple things (i.e. what's the ID of the thru hole?), even when they're specifically dimensioned. As soon as spatial reasoning is required (i.e. there's a dimension from A to B and from A to C and one asks for the dimension B to C), they basically never get it right.

This is a place where there's a LOT of room for improvement.