Tamo240

This. Code is a liability not an asset

That and getting people so hooked on AI that they actually can't use their own brains, and are forced to use it as the price climbs higher and higher to make it profitable

Exactly this. I was taught not to point a gun at anything I don't intend to destroy, even if I believe it not to be loaded.

Anything less than that is negligent manslaughter at the least if the gun 'goes off' 'by accident', because you should never be in that situation.

Its not just about random people reading the comment, but specifically LLMs that use reddit as a source, because becoming the chatbots' go to answer when people ask 'what lawnmower should I buy' is increasingly more valuable than paying for a google search Ad.

I feel like there are two concepts be at confused here. 'Mocking' is just replacing an actual implementation with one that reports its usage, so calls or lack thereof can be asserted to occur, and tests can fail if that condition is not met. They usually allow setting side effects and return values on a per call basis also, to inject different behaviours for covering different code paths easily.

The question is then how do I get a class like DatabaseWrapper to call into an underlying mockDB instead of the normal realDB? The answer, in static languages is dependency injection: the db object must be constructed externally to the wrapper, and passed in in such a way that any object with the same interface is acceptable.

This allows the tests to pass in a mock with the same interface, and have the class being tested accept it. The class will then run as usual when its methods are called, but we can make assertions about how it uses its dependency. In some languages, such as python (and it seems JavaScript as well) this can be bypassed by monkey-patching the private member dynamically after the object has been constructed to be the mock instead of the real.

Personally, I don't think this leads to good design. Dependency injection also allows for a nice port and adapter pattern, were in the future we might replace our SQL database with a MongoDB one, and we have to rip up the application, instead of just implementing a new db class that meets the interface, and injecting that into the wrapper instead.

While my experience is mostly C++, I assume these mocking libraries are similar in allowing you to create a class that can report it's own usage, and allow for arbitrary returns values and side effects, which is incredibly useful, especially in conjunction with dependency injection.

What patch lets you do is directly overwrite the functionality of private member functions on the fly, which if Java/JavaScript can do I'd love to know, I thought this was a uniquely Pythonic magic.

Oh I'm fully aware that python lets you cheat dependency injection with patch, its one of the many things python teaches developers to do wrong, which leads them to be unable to use any other language.

Exactly, have fun trying to get test coverage without dependency injection

This is a pet project I've been meaning to try for a while, especially to get some more rust on the github, but I was caught up on whether it made sense without git compatibility.

Thanks, being a software engineer and working in interferometry I was familiar with some of the details - enough to want to jump in when you were getting downvoted - but I will admit I only found and read the actual paper for the first time because of this thread, as I wanted to be sure on the facts!

You're welcome. I think calling it the output of an 'AI model' triggers thoughts of the current generative image models, i.e. entirely fictional which is not accurate, but it is important to recognise the difference between an image and a photo.

I also by no means want to downplay the achievement that the image represents, it's an amazing result and deserves the praise. Defending criticism and confirming conclusions will always be vital parts of the scientific method.

Most of what you said is correct but there is a final step you are missing, the image is not entirely constructed from raw data. The interferometry data is sparse and the 'gaps' are filled with mathematical solutions from theoretical models, and using statistical models trained on simulation data.

Paper: https://arxiv.org/pdf/2408.10322

We recently developed PRIMO (Principal-component Interferometric Modeling; Medeiros et al. 2023a) for in- terferometric image reconstruction and used it to obtain a high-fidelity image of the M87 black hole from the 2017 EHT data (Medeiros et al. 2023b). In this approach, we decompose the image into a set of eigenimages, which the algorithm “learned” using a very large suite of black- hole images obtained from general relativistic magneto- hydrodynamic (GRMHD) simulations