Readit News logoReadit News
fishstamp82 commented on Mathematicians disagree on the essential structure of the complex numbers (2024)   infinitelymore.xyz/p/comp... · Posted by u/FillMaths
grumbelbart · 18 hours ago
> Is this the shadow of something natural that we just couldn't see, or just a convenience?

They originally arose as tool, but complex numbers are fundamental to quantum physics. The wave function is complex, the Schrödinger equation does not make sense without them. They are the best description of reality we have.

fishstamp82 · 17 hours ago
The schroedinger equation could be rewritten as two coupled equations without the need for complex numbers. Complex numbers just simplify things and "beautify it", but there is nothing "fundamental" about it, its just representation.
fishstamp82 commented on Stonebraker on CAP theorem and Databases (2010)   perspectives.mvdirona.com... · Posted by u/onurkanbkrc
mrkeen · 11 days ago
I have no problem with ACID the concept. It's a great ideal to strive towards. I'm sure your favourite RDBMS does a fine job of it. If you send it a single SQL string, it will probably behave well no matter how many other callers are sending it SQL strings (as long as the statements are grouped appropriately with BEGIN/COMMIT).

I'm just pointing out two ways in which you can make your system non-ACID.

1) Leave it on the default isolation level (READ_COMMITTED):

You have ten accounts, which sum to $100. You know your code cannot create or destroy money, only move it around. If no other thread is currently moving money, you will always see it sum to $100. However, if another thread moves money (e.g. from account 9 to account 1) while your summation is in progress, you will undercount the money. Perfectly legal in READ_COMMITTED. You made a clean read of account 1, kept going, and by the time you reach account 9, you READ_ what the other thread _COMMITTED. Nothing dirty about it, you under-reported money for no other reason than your transactions being less-than-Isolated. You can then take that SUM and cleanly write it elsewhere. Not dirty, just wrong.

2) Use an ORM like LINQ. (Assume FULL ISOLATION - even though you probably don't have it)

If you were to withdraw money from the largest account, split it into two parts, and deposit it into two random accounts, you could do it ACID-compliantly with this SQL snippet:

    SELECT @bigBalance = Max(Balance) FROM MyAccounts
    SELECT @part1 = @bigBalance / 2;
    SELECT @part2 = @bigBalance - @part1;
    ..
    -- Only showing one of the deposits for brevity
    UPDATE MyAccounts
    SET Balance = Balance + @part1
    WHERE Id IN (
        SELECT TOP 1 Id
        FROM MyAccounts
        ORDER BY NewId()
    );
Under a single thread it will preserve money. Under multiple threads it will preserve money (as long as BEGIN and COMMIT are included ofc.). Perfectly ACID. But who wants to write SQL? Here's a snippet from the equivalent C#/EF/LINQ program:

    // Split the balance in two
    var onePart = maxAccount.Balance / 2;
    var otherPart = maxAccount.Balance - onePart;

    // Move one half
    maxAccount.Balance -= onePart;
    recipient1.Balance += onePart;

    // Move the other half
    maxAccount.Balance -= otherPart;
    recipient2.Balance += otherPart;
Now the RDBMS couldn't manage this transactionally even if it wanted to. By the final lines, 'otherPart' is no longer "half of the balance of the biggest account", it's a number like 1144 or 1845. The RDBMS thinks it's just writing a constant and can't connect it back to its READ site:

    info: 1/31/2026 17:30:57.906 RelationalEventId.CommandExecuted[20101] (Microsoft.EntityFrameworkCore.Database.Command) 
        Executed DbCommand (7ms) [Parameters=[@p1='a49f1b75-4510-4375-35f5-08de60e61cdd', @p0='1845'], CommandType='Text', CommandTimeout='30']
        SET NOCOUNT ON;
        UPDATE [MyAccounts] SET [Balance] = @p0
        WHERE [Id] = @p1;
        SELECT @@ROWCOUNT;

fishstamp82 · 4 days ago
For example 1) Let's be clear about what we are doing.

If you are running in RC isolation, and perform a select sum() from table, you are reading values committed by other threads BEFORE the select statement began, you are not getting other threads committed values during the select, you are not breaking ACID.

If you are suggesting that running a simple BEGIN; select sum() from table; COMMIT is breaking acid in a default RC level, you are wrong and should best avoid commenting on isolation levels in RDBMS online, to not confuse people further.

If you are however suggesting that we are breaking ACID if we do app side stupidity such as:

value1=BEGIN; SELECT value from table where id=1;commit value2=......

sum = value1+value2....+value10

Then yes obviously its not acid but nobody in their right minds should be doing that. Even juniors quickly learn that this is incorrect code.

If you are suggesting we do repeatable reads in RC then yes its obviously not ACID but your example does not mention repeatable summations only a single one.

fishstamp82 commented on Stonebraker on CAP theorem and Databases (2010)   perspectives.mvdirona.com... · Posted by u/onurkanbkrc
belter · 9 days ago
fishstamp82 · 9 days ago
Postgres as an example is ACID compliant if you want it to be. All those databases that have full serialization possible do utilize RC by default which is enough to prevent dirty writes and was my original point.

Thanks for the link still, it was valuable!

fishstamp82 commented on Stonebraker on CAP theorem and Databases (2010)   perspectives.mvdirona.com... · Posted by u/onurkanbkrc
mrkeen · 11 days ago
And then they take that toy transaction model and think that they're on ACID when they're not.

Are you stepping out of SQL to write application logic? You probably broke ACID. Begin a transaction, read a value (n), do a calculation (n+1), write it back and commit: The DB cannot see that you did (+1). All it knows is that you're trying to write a 6. If someone else wrote a 6 or a 7 in the meantime, then your transaction may have 'meant' (+0) or (-1).

Same problem when running on reduced isolation level (which you probably are). If you do two reads in your 'transaction', the first read can be at state 1, and the second read can be at state 2.

I think more conversations about the single "fully consistent" db approach should start with it not being fit-for-purpose - even without considering that it can't address soft-modification (which you should recognise as a need immediately whenever someone brings up soft-delete) or two-generals (i.e. consistency with a partner - you and VISA don't live in the same MySql instance, do you? Or to put it in moron words - partitions between your DB and VISA's DB "don't happen often" (they happen always!))

fishstamp82 · 11 days ago
RE: "All it knows is that you're trying to write a 6. If someone else wrote a 6 or a 7 in the meantime, then your transaction may have 'meant' (+0) or (-1)."

This is not how it works at all. This is called dirty writes and is by default prevented by ACID compliant databases, no matter the isolation level. The second transaction commit will be rejected by the transaction manager.

Even if you start a transaction from your application, it does not change this still.

fishstamp82 commented on Live Stream from the Namib Desert   bookofjoe2.blogspot.com/2... · Posted by u/surprisetalk
nxor · 4 months ago
Less youtube is my next big thing. My screen time is too high.
fishstamp82 · 4 months ago
I had this problem for a long time, the only thing that worked was installing an ad on that removes recommendations. The only thing I use youtube for today is intentionally following ASL (starcraft broodwar) in korea.

The ad-on makes the home screen completely white/empty, meaning I just get reminded constantly ohh, yeah I am not supposed to use youtube unless there is something particular I want to watch.

fishstamp82 commented on AI Adoption Rate Trending Down for Large Companies   apolloacademy.com/ai-adop... · Posted by u/walterbell
fishstamp82 · 5 months ago
The tickers for months are not obvious to me, and since its a 6-week moving average and not point in time, the numbers are a bit hard to intuitively grasp.

To me it looks like the drop is harder since averaging smooths out the points, so end of july 2025 the adoption is not exactly 12%, but probably more like 8%, where its closer to end of 2023.

It seems big tech is putting a big break on AI tooling, for now.

fishstamp82 commented on Microsoft is infesting Windows 10 with annoying ads (2017)   theverge.com/2017/3/17/14... · Posted by u/doener
whyhow · 6 years ago
I tried Ubuntu for the first time in years last month. At first I was pretty happy with it, but gradually I grew frustrated. Every time I would install a new library in R (statistical programming language) I would have to spend 10-15 minutes trying to figure out why it didn't work. I'd end up in this deep rabbit hole of missing dependencies that I never had a problem with in MacOS or windows
fishstamp82 · 6 years ago
I would recommend arch linux, everything exists in the aur and most things work out of the box.

Dont buy the hype that arch is hard, its a really simple system imo.

fishstamp82 commented on Warming Up to Unit Testing   junglecoder.com/blog/warm... · Posted by u/yumaikas
war1025 · 6 years ago
> If your code base utilizes dependency injection to make the code more "testable" with mocks, you are making the code 10x worse.

I don't know that I'd word it exactly like that, but one thing I've found over the years is any tests we have that rely on mocks basically just don't test anything at all.

If your whole test is "This gets called, then that, then that", you aren't actually writing a test. You're repeating what the code already says.

fishstamp82 · 6 years ago
I think verifying that your code calls this and that is that it actually works the way you expect. Without such test we might assume code works in one way when the happy path is not even reached.

I find it valuable at times, depending on the context, but I agree that extensive mock testing like this can get quite useless real quick.

u/fishstamp82

KarmaCake day4January 12, 2019View Original