I recall seeing in released emails about the Callendar Square bug that it's debatable as to whether what the system was doing was properly double entry. In that case, my interpretation of the emails was that there were transactions that were nominally recorded as multiple double-entry transactions, but involved, eg, a transfer from account A to a hidden outstanding account X, and a transfer from account from X to account B. Then the account X wasn't actually tracked anywhere or even expected to balance on any individual system: it appears that when multiple counters at the location were involved, the transactions weren't necessarily synchronized between them. In that case, if you have three £1k transfers from A to X (two of which are duplicates), and one £1k transfer from X to B, then it will look like £2k disappeared unless you check the balance of X.
To me, that sounds like an accounting system made by people who fundamentally didn't understand the point of double-entry accounting, because a double-entry accounting system that uses hidden or untracked accounts entirely removes that point and is just equivalent to a single-entry accounting system. Presumably, if all those transactions were properly stored and then combined, a full double-entry ledger could be reconstructed, but it appears the system itself couldn't do that in at least some cases.
Of course, there also seems to be the suggestion that part of the Post Office's argument to subpostmasters was that even if the problems were obvious, like clear duplicate transactions, they were still liable per the contract.
Nice little idea! As a slight aside I’m not sure where the timezone / city list has come from but it labels Hanoi as in Thailand (rather than Vietnam).
I guess the question would be, if indeed these suggestions would solve those problems, how much does this cost (I genuinely have no idea!) and how much do I want to spend on this versus putting up a webpage to direct people too.
I want to shave off every last ms of latency in the services I own but at the end of the day at some point it’s good enough (and best for the business) just to manage expectations.
IIUC cm precision should be fine if the algorithms looking for stable placement accounts for that cm (and reality id imagine it’d account for less precision than that). If a placement needs sub cm precision the algorithm would just discard that option.
Additionally there shouldn’t be any accumulation in a specific direction. Any accumulated gaps would be accounted for when placing the next rock and rectified to within a cm.
A store’s opening hours will probably remain 9am-5pm regardless of any time zone changes around it. If you run a bunch of stores across time zones you need to know where each store is and whether it’s summer or winter to work backwards to find out 9-5 in UTC.
Makes we wonder how much of the investor’s money was put in to OpenAI as a company or in Sam and the leadership. I think the answer is probably the latter, and the fact that Sam’s firing was this easy (and would likely have the effect of others going in quick order) seems like a massive oversight in terms of investor due diligence in board structure etc.
I feel like trying to infer valid JSON from invalid JSON is a recipe for garbage. You’d probably be better off doing a second pass with the “JSON” through the LLM but, as the sibling commenter said, at this point even the good JSON may be garbage …
I want to hear that at normal typing speed. I feel like, unless there are a good amount of slightly varied samples, it's going to have that TR-808 repetitive vibe going on ...
I was also put off by the static, repetitive sounds. My suggestion would be to record 5-10 sounds and pick randomly, slightly tuned them up/down with some filtering.
That should really be recorded in stereo and at least 20 samples for each key, possibly at different strength and then some sort of algo that would pick samples depending on how vigorously someone types.
Then that still wouldn't capture the intermodulation etc.
It's a lot of work to actually make it sound remotely realistic.
Maybe the sound should be played in proportionate intervals to typing speed, rather than upon "hits", with the last one somehow cleverly ending with key-up and/or first key-down inevitably absent.
