The Mathematica programming language does what you describe for symbolic math when representing exact numbers. “Arbitrary” might be a bad label, the number is exactly represented by a rational fraction. It’s doable, but I’m unconvinced that it is worth the trouble/effort.
Maybe elders don’t need to store the chunks, but the rubber needs to meet the road at some point. Every vault storing chunks will need to be audited, continuously, in order to ensure that a minimum of N copies actually do exist simultanously within a given interval of time and that no bit rot has occurred due to hardware issues or malicious nodes.
Arbitrary precision is in reference to the integer numerator and denominator. If fixed width types are used instead, then there is still a smallest unit of divisibility for a fraction. Arbitrary precision integers, such as offered by gmp, allow integers of any size, limited only by the machines memory.
I would wager that Mathematica is using arbitrary precision.
Ok, I see what you meant now.
yes, it is the exact representation that I find intellectually appealing. It just seems so “clean” and “correct” vs rounding approaches. To me, provable correctness has such a beauty as to be an end-goal in itself sometimes, and all the benefits that result may not be realized until later in the game.
I think some of the “trouble/effort” stigma is just that… stigma, and fear of the unknown. Today, there are well tested, efficient libraries available for using rational numbers. But we (in cryptocurrency community) keep doing things the way they’ve always been done.
Except really money as decimal/integer is not the way things have always been done. Fractions have been used for coinage historically eg the spanish used “pieces of 8”, the british had the farthing which was 1/4 of a British penny or 1/960 of a British pound and they even used 1/2 and 1/3 farthing in the colonies. The US stock market still uses fractions as it was originally based on the spanish system.
All that said, I’m truly not advocating to change the SafeCoin u64 approach at this point. It’s more of a fun idea to think about in context of cryptocurrency in general, and particularly for dividing mining rewards equitably, and/or for enabling unbounded divisibility of base unit as it rises in value.
And guess what we still went to fixed point for financial in light of fractions giving exact numbers.
Also a coin that is a fraction is not the issue in question. Nor is shares as a fraction. We are talking of 70 years of computer science and financial programming has not seen the need for exact fractions and its just a purism to want it.
But people do not think in fractions for financial processing, even the US “quarter” is simply 25 cents so is not really a fraction.
I have yet to hear the reasons why we should go against 70 years for computer science and a century of using fixed point for financial.
I agree that it is nice, but honestly it will confuse the hell out of non-tech/mathematical people when they try to understand safecoin. “Why can I not give you one safecent but have to give you 1/100th of a safecoin” OR why can I not give you 4 safecents but have to give 1/25th of a safecoin when i just want to tip you 4 safecents. People will have to reverse think to think about it. AND if you say lets do both then give up having safecoin because the confusion in the typical person will mean they say “stuff this I will not move to this garbage”
Ah, the smell of money. A safecent safe sent is a safe scent indeed.
@neo you are debating a strawman. I’ve clearly stated I am not advocating changing the SafeCoin denomination. If I were, I would publish a formal proposal for such, and for the record I have no intention of doing so.
But people do not think in fractions for financial processing, even the US “quarter” is simply 25 cents so is not really a fraction.
Perhaps not most people today, but clearly people are capable of it, even illiterate people. The spanish real, aka piece of 8, aka Thaler lasted much longer than the US Dollar has yet been in existence. Fun fact: the “quarter” you reference is so-called because it is 1/4 of a dollar, and was created specifically as an exception to the 100 base system because it would trade 1:1 with the popular 2 pieces of 8 (aka 2 bits). The other US coins were divisions of 100: 1, 5, 10, 50, 100. So the quarter is really an odd-ball.
The pieces of 8 system really made more sense than decimal system when you think about having a physical unit of a given metal, ie silver. It could then be divided in half (4/8 aka 4 bits), and that in half (1/4 aka 2 bits), and those in half (1/8 aka 1 bit). Very easy to make change, typically with just one coin. Try that with a nickel and a penny.
Anyway, please, please, let’s not debate any further about representation in financial software.
I have yet to hear the reasons why we should go against 70 years for computer science and a century of using fixed point for financial.
I’ve clearly articulated why I found this an interesting concept to discuss. If you are interested, you can find them above in the thread. I will not be replying to any further debate about it as we are clearly talking past eachother at this point, and as I’ve said a few times now, I am not seriously proposing to change the SafeCoin u64.
I must have misread some of the posts then, I mistook some of the talk as leading up to a push for it. Accept my apologies and rest assured the strawman was not intentional.
For a maths package, yes I can see many benefits for this, so many areas would benefit. Just not for financial, sorry
Thats easy for you to say.
I thought it was supposed to be u128?
I will defer to others on the latest with that. My statement was based on rfc-0057.
I’m almost afraid to throw more fuel on the fire here, but I just found this article which I think gives more weight to my rational number for money idea.
Haskell has a library called safe-money
that implements money as either discrete
or dense
types, the latter being a rational number.
A couple quotes:
However, integers are still not enough for all our needs. We can identify at least two problems with this approach. The first problem is representing currencies that don’t have a “canonical smallest unit” like USD had in the cent. Think of precious metals, for example. What is the smallest unit of gold? Is it a kilo? Is it a gram? Is it a tenth of a gram? Is it a troy ounce? There’s no correct answer. For all practical intents and purposes, you can repeatedly split your gold into smaller pieces and still call each of the smaller pieces “gold”. So, since we can’t find a canonical smallest unit for this currency, we can’t count our gold as a whole amount of them. Otherwise, we’d be unable to count pieces smaller than any arbitrarily chosen smallest unit. And yes, presumably we could treat the atomic mass of the gold atom as our smallest unit, but that would be rather small and unpractical.
A more subtle problem with integer numbers is representing intermediate values. Say, what is the half of 5 USD cents? It is 2.5 cents, but of course can’t be represented as a whole amount of cents. An “alternative” result, 2, is an approximation in which we lose 1 cent. 3 is another approximation in which we make up 1 cent. But we already know that losing or making up money is not acceptable. Yet, values such as “half 5 cents” are important even though it’s impossible to represent them using coins or other tangible currency support. In particular, these values are very important when they are the intermediate results of some calculation. Suppose you want to write a function that calculates “ten times half of its input”. That is, f x = 10 * (x / 2). If our input is 5 cents, ideally, we would get 25 cents as a result, which is a perfectly representable whole amount of cents. However, if the intermediate result for x / 2 would have been rounded down or up, we would have gotten either 20 or 30 cents as result, respectively. Generally, this is unacceptable when dealing with money, so integer numbers are not sufficient representation for monetary values for manipulation purposes. What is the answer then?
The correct way of representing monetary values for manipulation is as rational numbers. Rational numbers always give precise results, they don’t introduce rounding errors and they don’t require us to acknowledge a “smallest representable unit”.
Seems like you’re missing a link?
hit ctrl-enter by accident. fixed now. you are quick.
I think rational numbers might be a serious option. Cryptos have different characteristics than fiat currency.
Fiat is inflationary, so rounding errors become less of a problem over time. So no one cares
Crypto is deflationary, rounding errors become more significant over time. This is a new situation, so you can’t compare the old financial tech with crypto IMO.
Performance…it will only be an issue when you make a lot of calculations in a very big loop. It’s negligible in this usecase. Some calculations can also be done client side, but still… it’s nothing compared to software that do optimizations etc
The only thing is, the user should not be bothered with rationals.
I just gotta be “that guy”… The smallest unit you can divide gold down to is an atom. Anything smaller and it ceases to be gold.
@JohnM They addressed that actually, just for you:
And yes, presumably we could treat the atomic mass of the gold atom as our smallest unit, but that would be rather small and unpractical
Oops - they sure did - read it too quick!
Not the case for crypto though. It is easy to account for “atoms” of SAFE with a uint128 or higher bignum.
2^128 = 3.40282367 × 10^38
Avogadro’s constant = 6.02214076×10^23 mol−1.
This means we have about 10^15 grams of SAFE in existence.