Spanish traders set the standard for GnuCash database design

Side question:

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.

> So, unless you are a Spanish trader from the 16th century or have a book with fractional stocks from the 90s, HandsOnMoney will serve you well.

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...

> 1. Japanese Yen has no minor units (due to post-WWII inflation)

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!

I committed to the GnuCash codebase pretty regularly in the 1999-2002 era... I think maybe I actually implemented the fractional representation that the article discusses? Not sure, it was a long time ago! I definitely remember receiving some very heated emails about how this was total nonsense and there was no reason to do anything other than a decimal representation. The phrase "a superhighway of abstraction, leading nowhere" has stuck with me for lo these many years :) good times

I used GNUCash years ago in Argentina while we had high inflation. Some operations were in local currency and other are Dollars. The currency exchange changing hourly. Tracking finance is a nightmare, since you basically need an exchange rate for every operation.

I wonder if Hackernews ranking algorithm has been updated to exclude comments toing and froing about whether or not the article is LLM generated!

I would like to use finance tracking products like GNUCash. But I don't have the patience to download the csv for half a dozen accounts every month (Products like plaid are a no go from a basic security perspective). I am in Canada, and there seems to be no hope that I will have API access to my bank accounts anytime soon.

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.

Feels ai generated and waste of time to read even though the topic could be interesting.

The discussion on Spanish traders set the standa raises interesting points. In practical applications, the key challenge is balancing performance with maintainability. Would be valuable to see more concrete examples of trade-offs.