If you took a transcript of a conversation with Claude 3.6 Sonnet, and sent it back in time even five years ago (just before the GPT-3 paper was published), nobody would believe it was real. They would say that it was fake, or that it was witchcraft. And whoever believed it was real would instantly acknowledge that the Turing test had been passed. This refusal to update beliefs on new evidence is very tiresome.
Similarly if you could let a person from five years ago have a spoken conversation with ChatGPT Advanced Voice mode or Gemini Live. For me five years ago, the only giveaways that the voice on the other end might not be human would have been its abilities to answer questions instantaneously about almost any subject and to speak many different languages.
The NotebookLM “podcasters” would have been equally convincing to me.
While being more opaque & difficult to self-correct for. How much more work are we talking about? A theoretical couple of minutes in a year? Not worth it.
Using the scheduler estimates from the FSRS simulator [1], for desired retention held equal at 85%, I received approximately 20-30% improvements in workload upon switching to FSRS from SM-2. Even disregarding the "internal" improvements, the ability to reduce the number of parameters that require modification/present risk to performant scheduling is heavily reduced to only setting desired retention explicitly (a benefit in and of itself) as well as minor decisions (e.g. inclusion of suspended cards). Interpretability really is far less of an issue than efficiency, and frankly the achievements of the team behind FSRS (including their decision to make it publicly available) should be lauded.
Ok, I've identified the root of my confusion here. Mochi has two FAQs:
https://mochi.cards/faq.html Mochi uses SM-2 without EF adjustment and without resetting intervals. This is outdated.
https://mochi.cards/docs/faq/ says Mochi multiplies by a number >1 on recall and by a number in [0,1] on forgetting. This FAQ is linked from the front page and seems to be the correct one.
And, indeed, checking the review settings for my deck shows the multiplier settings.
Hey sorry about that. I will take down the old FAQ, or at least redirect it to the new one. The other thing not mentioned in that section of the FAQ (that I will add now) is the re-review phase. When you miss a card during review it will go to the re-review queue. Missing it again in that phase will reset its interval to 1.
Since I created Mochi there have been some new algorithis developed. Most notably FSRS [0] looks promising.
I don't have any issue falling asleep though... only staying.
But I can try, I even that at home. Last I tried, it had opposite effect (same with magnesium).
The point about the storage size of UUID columns is unconvincing. 128 bits vs. 64 bits doesn't matter much when the table has five other columns.
A much more salient concern for me is performance. UUIDv4 is widely supported but is completely random, which is not ideal for index performance. UUIDv7[0] is closer to Snowflake[1] and has some temporal locality but is less widely implemented.
> The point about the storage size of UUID columns is unconvincing. 128 bits vs. 64 bits doesn't matter much when the table has five other columns.
But it's not just the size of that one column, it's also the size of all the places that id is used as a FK and the indexes that may be needed on those FK columns. Think about something like a user id that might be referenced by dozens or even hundreds of FKs throughout your database.
think of the primary keys in a database like typedef void* ie it's your fundamental pointer and the size of it will impact every aspect of performance throughout - memory/disk footprint and corresponding throughput bottlenecks, cpu time comparing keys which is what every operation reduces to in the deepest inner-most loops of joins and lookups etc.
when x86-64 cpus were new the performance impact from switching to 64-bit pointers was so bad we had to create x32/ilp32 and the reason .NET still has "prefer 32-bit" as a default even today.
using 128-bit uuids as PKs in a database is an awful mistake
Prefer 32-bit does nothing for modern .NET targets. This is actually the first time I've heard the term being used in many years, even back in .NET Framework 4.6.x days it wasn't much of a concern - the code would be executed with 64-bit runtime as a default on appropriate hosts.
the 32bitpref corflag isn't part of a .net core target since those are always il, it is more properly a runtime concern as it should be
it's still the default in .net as of 4.8.1 (has been since it was introduced in 4.5 roughly coinciding w/java's pointer compression feature which is also still the default today)
The .NET Framework target might as well not exist :D
Many libraries are straight up dropping NS2.0 TFM and overall community tends to perceive the request to still target it very negatively. Sure, Visual Studio still runs some in-process features on top of it, and so do Office add-ins, but it's an active work-in-progress to get rid of any new code having to be written while still targeting it.
The v7 isn’t a silver bullet. In many cases you don’t want to leak the creation time of a resource. E.g. you want to upload a video a month before making it public to your audience without them knowing.
This maintains many of the benefits of sequential indexes and does allow you to change the key. However, if the key is changed, it would break any bookmarks, invalidate anything sent in older emails -- it would have the same effect as renaming everything.
It very much does when you have a ton of FKs (enforced or not) using such a column, and thus indexed and used in many joins. Making it twice as hard for the hot part of an index to fit to RAM is never good for performance, nor for the cloud bill.
If you have a column that is used in many joins, there are performance reasons to make it as compact as possible (but not smaller).
If I’ve learned anything in my 7 years of software development it’s that this kind of expertise is just “blah blah blah” that will get you fired. Just make the system work. This amount of trying to anticipate problems will just screw you up. I seriously can’t imagine a situation where knowing this would actually improve the performance noticeably.
Would it ever make sense to have a uuidv7 as primary key but then anther slug field for a public-id, e.g. one that is shorter and better in a url or even allowing user to customize it?
That and a uuid is going to be unique across all tables and objects, whereas a slug will only be unique within a certain subset e.g. users within an organization. I’ve seen a production issue IRL where someone (definitely not me) wrote a query fetching objects by slug and forgot to include the ‘AND parent_slug = xxx’
>Now scientists have used mathematical techniques to compare patterns in the “social networks” of characters in Ossian with those in two key Irish stories – and discovered they are almost a perfect match, virtually ending any remaining debate.
Seems like a flimsy argument, irrespective of the other evidence.
Not really. If I write a series of stories about Herlock Solmes and his friend Dr. Wohn Jatson and everything maps up one-to-one with the Sherlock stories, it's pretty clear I copied them even if I changed the names. Or to give a real example, consider the famous silent movie "Nosferatu". While it was theoretically about a vampire named Count Orlock being visited at his castle by a lawyer named Thomas Hutter and how Orlock ends up moving to Hutter's city and attacking his family, it is pretty obviously the story of Count Dracula and Jonathan Harker, and the widow of Dracula's author sued the makers over it.
If you took a transcript of a conversation with Claude 3.6 Sonnet, and sent it back in time even five years ago (just before the GPT-3 paper was published), nobody would believe it was real. They would say that it was fake, or that it was witchcraft. And whoever believed it was real would instantly acknowledge that the Turing test had been passed. This refusal to update beliefs on new evidence is very tiresome.
reply