MS Excel uses floating point, and it's used a ton in finance. Don't use floating-point for monetary amounts if you don't know what rounding mode you've set.
Integer cents implies a specific rounding mode (truncation). That's probably not what you should be using. Floating point cents gets the best of both worlds (if you set the right rounding mode).
Obviously you can't accumulate cent by cent. You can't even safely accumulate by quarter. Epsilon is too large to do that. I calculate cumulative pnl using std::fma, then multiply AUM with that and round to cents. It's good enough for backtesting, and it shaves a bunch of seconds off the clock.
I see - I guess it's a financial modelling program or similar where the quantities don't represent precise values of money. I was imagining some kind of accounting-like app that would need to be reconciled with real-world balances.
I saw some answers but one potential roadblock is runtime, it looks like google transpiler generates a boolean circuit, which is kind of like emulating a small piece of hardware in software
Potentially do stats on website usage data without ever seeing the actual data (the endgoal is not super humanitarian I know). Medical diagnosis could be one, bonus is the service never sees your data.
As per conditional programs, there might be a way to do it but it would always be the worst case (no early loop break for example) so the runtimes would be aweful and the memory state could get prohibitively large I guess (to keep track of all the branches).
My guess would be usability, the google approach let's anyone knowing C++ (constrained by the supported sets of operations from the language) actually create an FHE program without having to know anything about crypto.
Maybe PALISADE is not user friendly enough? Just a wild guess I never used PALISADE
The idea today is that you rely on sharing a key with the server (through a secure protocol) but the server still has to decrypt your data to do anything with it and then encrypt it back and send the result to you.
With FHE, if the server runs FHE software then you can encrypt your data with your secret key without ever disclosing it to the server (as it does not need it to compute stuff on your data).
The benefits are many: the server never has to know anything about your data (imagine a MedTech company doing diagnosis, your medical data will be safe from their prying eyes).
If the server is compromised, the attacker cannot look at your data, potentially no more private information leak!
On the regulatory side you potentially don't have to worry about GDPR anymore, you can't access the data of your users.
Also, you don't have to care where the data is being stored, because if it's fully end-to-end encrypted, location is far less of an issue (to your GDPR point). Alleviates a lot of the talk around the security risks posed by the unrestricted sale and transfer of sensitive data to foreign adversaries (China, Russia) that dominates the political landscape in the U.S.
