Spanish traders set the standard for GnuCash database design
handson.money
handson.money
I'm surprised by the explanation of the 8 in the "real de a a ocho" because "traders counted gold doubloons on their fingers, skipping their thumbs." (and the link to investopedia has a similar explanation).
But from https://en.wikipedia.org/wiki/Doubloon
> Spanish American gold coins were minted in one-half, one, two, four, and eight escudo denominations, with each escudo worth around two Spanish dollars or $2. The two-escudo (or $4 coin) was the "doubloon" or "pistole", and the large eight-escudo (or $16) was a "quadruple pistole"
I think it makes more sense that some time ago it was possible to split some coins in half and quarters, so someone decide to continue the tradition and use base 2 to move up.
But then why didn't they cut it into 10 pieces - https://etc.usf.edu/clipart/40600/40610/pie_01-10a_40610.htm ?
Ever tried cutting a cake? It’s a lot easier to visually judge half of a circle segment. You’d need a compass to get accurate tenths (or fifths) and I imagine it is generally frowned upon if some tenths are a lot smaller than others (happens a lot with cake)
1 guinea = 1.05 pounds
You purchase the horse in guineas, seller gets paid in pounds, auctioneer keeps the missing 5% as commission.
[Time sink warning] [Fractions warning]
There is an interesting video by Lindybeige that explains the old British coin system. The part about the guinea is at minute 42, and in particular explains why it was worth 21 instead of 20.
US treasury futures are still priced in 32nds of a dollar increments. Sorry, that's not true, they're quoted in 32nds, but sometimes priced in half-, quarter- or eighth-32nds. One might trade at 105-22.5, which means 105 and 45/64ths.
https://www.cmegroup.com/trading/interest-rates/basics-of-us...
I knew there will be something to hunt minor units.
Commodities I think no longer do, but did until recently.
Japanese yen do have minor units, and they are confusingly called sen (which is a homonym for one thousand)
Now a days they are mostly used for stock prices. But they exist!
The current value of held assets in another currency isn't really "counting" any more, it's a prediction of the outcome of some future transaction that hasn't happened. So I'm less concerned about exactly computing it than I am in never making a mistake in assets that I am counting, i.e. keeping in one account and only incrementing and decrementing the amount when a transaction occurs.
Also, did I mention how much it annoys me that the transaction description differs between the CSV and the PDF statement for pretty much all banks I use.
But I used to actually pull the CSV once a week and feed it to GnuCash. It's pretty good at auto-categorization.
Also I simplified my finances to only a couple of checking accounts and only one credit account (for car rentals).
There needs to be a lot of investment in training and safe defaults though. Most people are not ready to automate even a little of their banking like that.
I would even prefer banks had the option to push data to trusted feeds than having open APIs you could call on your own.
I definitely do not support an API for doing financial transactions. That will result in so much hacking and theft.
- people do not trust Plaid and Finicity - data is captive inside of bank portals - each damn CSV has it's own format
But it still beats downloading multiple exports from the bank and importing it manually...
Me, I use plain-text accounting (hledger) that automatically imports the CSVs from my bank and categorizes transactions automatically, and I wrote some quick scripts using Python to import the PDFs from my brokerages and paystubs. It's not automated pulls but I only have a handful of accounts so it's really not a pain to manually pull statements once a month and run the import scripts. It takes me longer to reconcile everything to the penny then it does to do the imports, and it's a whale of a lot faster than manually entering through GNUCash. Plus, it's plain text so all you need is vim, git, and the command line.
The missing piece for me was a mobile app. So trying closing this gap with HandsOnMoney.
But I'll be honest - I'm putting off the statement import as much as I can until my financial anxiety kicks in.
Then GnuCash has features to match up financial institutions data exports against your transaction splits, see the discrepancies, and then reconcile against their PDF statements.
It's a way of life, but you always know what money you have, where. Although that sounds like something for wealthy people, I'd say it's actually more important the less money you have.
But now I am ruined by smartphones, which are way too slow to type in every transaction manually.
You're introducing a currency that does 1/8ths. A computer can handle that a lot better than decimal.
P.S. Doubles are absolute evil for calculations:
@Test
func test() {
var a = Decimal(100.4449315513924) * 100 // It's me being dumb, not noticing that
let b = NSDecimalNumber(decimal: a).intValue
#expect(b == 10044) // Expectation failed: (b → -8402) == 1044
}Storage as an integer often adds complexity because of currency reforms. Decimals can and have been dropped in the past.
Thing is - I'm not a English speaker. But I chat a lot with Claude/ChatGPT - i feel like I'm picking the style from them unintentionally.
Just imagine a prompt: "Hey Claude, go ahead and come up with idea why GnuCash stores numbers as fractions and come up with an article for HN". I actually tried it and god damn thing came up with something very similar :D
Article ends with this
Keep up the good work!
Anyone reading this and who is complaining that it's too long and content-light? Respectfully, you really need to check yourselves, you're probably the one with the "internet brain" dopamine or whatever problem. This is NOT an unreasonable amount/style of words for what is said.
There's also a `Surprisingly written by a human :)` at the bottom.
Furthermore, it didn't feel LLM-generated to me. Quirky, yes; nothing wrong with that.