I voted for
dirvinoshi
because LOL!
Edit: I like div.
Did you mean the way in which div for “division” in addition to mathematics can also be a slang play on words for “the vision”? (or “two visions” I suppose…)
That was not in my mind at that moment, but there you go. We seem to always come back to div or divs one way or another.
Based on the poll results and the commentary that followed, I decided to propose the following structure for discussion. I’m not sure if this qualifies as a draft “micro RFC”?
A naming scheme and fractional denomination convention for Safecoin divisibility.
Summary:
In accordance with the specifications set forth in the Project SAFE whitepaper and related documentation, we define the total population of Safecoin as that represented by a 32bit address space, yielding the total number of Safecoin in existence to be 2^32 = 4294967296. Any Safecoin can be subdivided into an additional 2^32 subunits, each of which shall be known as irvine by definition. This forms a primary non-decimal fractional denomination system.
In consideration of potential future requirements for higher order divisibility, we define the unit irvine to be subdivided into an additional 2^32 subunits, each of which are referred to as a troon. Lastly, a single troon is subdivided futher into an additional 2^32 subunits, each of which are referred to as an ayr forming a tertiary non-decimal fractional denomination system. Any or all fractional denominations used for Safecoin divisibility will be commonly referred to as a div or divs in pleural form. A total resolution for the entire population of Safecoin in existence that is greater than 128bits will not be considered at this time.
- 1 Safecoin = 4294967296 irvine(s)
- 1 irvine = 4294967296 troon(s)
- 1 troon = 4294967296 ayr(s)
Abreviations
- Safecoin : S
- irvine : irv
- troon : tro
- ayr : ayr
Alternate abbreviations generated by changing case or reducing letter count lead to naming conflicts with other terms in common parlance. (Ex. sans or serif font where s=second, t=time, i=imaginary, a=angstrom, Sc=Scandium)
Symbols
- Safecoin : TBD, candidates include Ⓢ, 𝕊, 𝔖, or Ꞩ .
- irvine : TBD, candidates include ⓘ, 𝕚, 𝔦 .
- troon : TBD, candidates include ⓣ, 𝕥, 𝔱 .
- ayr : TBD, candidates include ⓐ, 𝕒, 𝔞, Δ .
By convention, abbreviations or symbols should always follow numeric quantities separated by a space. This adheres to a similar notation used for common scientific units such as kilograms or newtons or ratios thereof. (Ex. One-hundred Safecoin = 100 S, One-thousand troons = 1000 tro, “The fixed internal exchange rate is naturally 2^32 𝕒/𝕥”). It is anticipated that these will not be misconstrued as common scientific or math symbols if portrayed in a unique font or if a common mathematical symbol is rare or esoteric to most users (ie. 𝕊 for Sedenion sets).
Justifications:
-
The total 128 bit address space described above is the minimum bit depth that allows for Safecoin resolution that is approximately infinite according to IEEE 754. Forum discussions on a minimum acceptable amount of Safecoin divisibility echo similar concerns regarding minimum allowable ipv6 resolution. Ultimately it was decided to go with a 128bit address space for ipv6. Following this same standard for Safecoin divisibility provides a second means for justification and easy media optics, since a Safecoin resolution equivalent to ipv6 resolution builds on the same foundation of accepted reasoning.
-
The naming choice for the different Safecoin div denominations ie. irvine(s), troon(s), and ayr(s) results from a simple investigation of the geographic locale’s in Ayrshire, Scotland where (presumably) the majority of SAFE Network development/innovation has occurred. This choice is analogous to the way in which novel chemical elements on the periodic table are often named after the geographic location where they were discovered. (ex. Strontium, Tennessine, Europium, Californium, Livermorium, etc )
-
The common term div is used to refer to any one of these denominations and serves as an easy means to describe some type of division or divisible unit of a Safecoin. Thus, an irvine is a type of div, a troon is a type of div, and an ayr is also a type of div; they’re simply divs of different magnitude.
Decimal vs. Non-Decimal Denominations
Some users consider a direct decimal system to be preferred over a non-decimal denomination system. In this case only a subset of the total address space within each denomination can be used. This would allow for 1e9 irvines/S, 1e9 troons/irvine, and 1e9 ayrs/troon. The use of a decimal vs. binary denomination system has pros and cons where either one causes round-off when converted in terms of the other. It would seem that there is little need to limit the resolution in this fashion by going with a straight 1:1 decimal system since any decimal value in terms of Safecoin would be accurate to 96bit precision if a binary denomination system is employed, and fixed point integer mathematics for 3 binary subdivisions is also rather straightforward. Furthermore, direct decimal denominations would appear to superficially break with the initial Safecoin whitepapers that described a system capable of at least 2^32 primary divs per Safecoin. It is therefore more logically consistent to follow an identical 2^32 secondary div per primary div scheme for higher order levels of divisibility.
Additional Naming Conventions:
Following justification #2, alternatives for unit div denominations are irvinium, troonium, and ayrium, although it is more appropriate to only employ these terms when refering to a large set of irvines, troons, or ayrs. (Ex. Future Collector A says, “How much troonium would you like for that great digital artwork?” Future Artist B responds, “It’s not that much in demand so just send 2^6 troons and we’ll be square.”) Although more controversial, for consistency the same could be said for the definition of a singular term used for describing the total set/population of all 2^32 Safecoins (ex. Safe, Safenion, Saferium, Safenium).
1 Like
Are you proposing that divisions are their own data object like safecoins are?
Each irvine being a data object?
Dirvinshi is a good name
No, not necessarily. There are a variety of efficient ways to handle divisibility via mutable data structures. This is just a set of proposed naming conventions and terminology for the different levels of divisibility to be employed.
I prefer the decimal system. Too hard to work with 1/2^32 when working out things.
I sell 1Kg of things for 1 safecoin then what is 100 grams of it cost?
if you use your irvines then its 429496729.6 irvines. Notice its not even whole irvines, there is a decimal six.
Why not just 0.10 safecoins. I am sure I read a couple of things around that. We want non-technical people to be comfortable using the system and binary just is not simple for them. Have safecents. Or just use a number 1 to 1,000,000,000 for irvines. Even bitcoin used 100,000,000 instead of binary.
1 Like
“highlander” because…
1 Like
Binary has some nice multi-scale properties (any quantity of Safecoin is a 4 digit number with 2^32 cardinality for each digit), but I understand the predisposition most people might have (10 fingers, 10 toes) towards always working with decimal amounts. Binary or decimal transactions could be handled just fine at the safe-app level even if the proposed binary system is used in the underlying data-structure. Regular users would be oblivious to the details in most cases unless they wanted to dig into the details, just like most people are unaware that minimum bitcoin resolution is IIRC 1500 satoshi, not 1 satoshi.
In all of your examples you are only using 2 or 3 significant figs of decimal precision, the binary system presented above has about 29 significant figures of decimal precision, while the decimal version using 1e9 divisibility per denomination has 27. In other words the binary can always match the decimal transaction to the same level of accuracy.
Example :
User A requests 0.1 S from User B. User B opens their safe app wallet/purse and enters 0.1 S and hits ‘send’. Under the hood, the following conversion occurs to facilitate the network transaction :0.1 S <= 429496729 irv + 2576980377 tro + 2576980378 ayr
In order to satisfy the seller you had to send an additional 0.4 ayr to round up to the nearest whole number ayr. Recall that 1 ayr is less than 1.26217744836e-29 S; so when viewed from the perspective of a decimal system, the amount that gets transferred to User A and shown in their safe-app wallet is 0.100000000000000000000000000005 S (if the sapp even bothers to display that many digits).
Whenever currency denominations are used in the real world, buyers and sellers need to come to an agreement. This is also the case for decimal systems. When buying gasoline (USA) how do you purchase a gallon for the list price of $2.9954321 if you only have 2 paper dollars, 9 dimes, 1 nickel, and 5 pennies? I could also turn the tables around and ask you, “Why not set the list price for your 100 grams of chocolate to 430 Mirv?” The answer of course is that humans find numbers closer to 1 on either side of the fractional point more aesthetically pleasing. That’s why we say 500 trillion instead of 500000000000 thousand when talking about the derivatives bubble, or $3 for a gallon of gasoline, and why paying 0.000032 BTC for anything is rather unsightly. Also consider the case where valuations of Safecoin in terms of other currencies skyrocket, such that 1 irv = 0.30 $. In that case you would probably be making transactions directly in irvines, and the conversion of a single ayr to decimal dollars would be $1.62630325873e-20. Worried?
All this being said, I am not opposed to going the scientific notation route and just using S, milli-S, micro-S, nano-S etc in the UI. The main idea here is to advocate for a fractional resolution of 96bits. The question then becomes how do you do the 96bit accounting behind the scenes. This is most simply done using an array of three 32bit unsigned integers. So irvine, troon, and ayr become pet-names for the respective integer values at index 0, 1, and 2 of this array. Exposing the direct accounting to the user as a wallet option adds a bit of fun, flexibility, and culture. I view using the entire precision offered by a 32bit unsigned int preferable to only allowing a max integer of 1e9.
I failed to understand your response to my quote.
I guess this has no connection to the previous posts - I like the name dots 
You know as well as I do that it was an example. If you add 64 bits (like you did) you get a practical infinite whole number on the order of 10^18 So rather than 2 places you get 17 or 18 places. And even if you use 32 bits you get 9 places.
Decimal is simply limiting max integer value of the binary. And I read the balance idea and since you don’t define data objects for each 1/2^32 unit then you too have a form of a balance. So limiting 2^32 to 1,000,000,000 is no problems and it means that 96% of the population can understand the fractional safecoin. If you choose binary then all the APPs will need to approximate most fractional safecoin amounts and present to the users a decimal fraction anyhow. So why not just do like most systems do and just keep it to a decimal system.
To go to binary then you are actually converting the decimal fraction the user entered for a spend to the nearest binary, then do the transfer then report all the amounts as decimal again. Double conversions for no good reason. The only reason I can see is you want to satisfy your itch for working only in binary to the determent of 96% of users.
And if you did decimal from the start then you don’t get these errors. Why stick to binary. BTW I started programming by programming machine code and entering the program in binary. So do understand binary as well as my native language.
I think I clearly mentioned that fractional denominations of decimal form are also popular, and so I think it’s good for you to take up that side of the argument. I was hoping some good discussion would come out of the micro-proposal. The point of this was to nail down some safenetwork community consensus on naming scheme terminology so we could all use a common set of terms when discussing things, a consensus on maximum required bit depth resolution for the total Safecoin digital resource (aka “Safenium”?), and a determination on binary vs. decimal representations.
Some of my reasons for preferring the binary system, which I alluded to above:
-
IIRC for the crowd/presale, it was stated that the total safecoin in existence would be fixed to 2^32, and that each safecoin shall be capable of achieving 2^32 primary divisions. This constraint is not attainable when limiting to a primary decimal system with up to 1e9 irvines/S.
-
Part of SAFE philosophy is “let the user decide”, right? Using a binary representation under the hood satisfies both user preferences for either binary or decimal as needed. This is not possible when only using a decimal system from the start.
-
The concept of limiting the network to 2^32 data objects and then representing safecoin divisibility via a balance method should not solve one problem and then impose another problem or constraint in other ways. A hybrid method may likely be most optimal. As the network grows, a primary form of divisibility that increases the number of data objects as described in the whitepaper may provide performance benefits. If you go with a binary system for irvines, then this hybrid situation is easily accounted for and the balance method takes up the slack for the remainder of higher order divisibility concerns. This is not possible when only using a decimal system from the start.
-
A single 4 digit number having 2^32 cardinality represents any quantity of safecoin (Ex. 123.324098.1232943.12343 ). This is a rather elegant mathematical representation. If for some reason all but 1 safecoin were burned or lost, or just not circulated due to “super-savers”, a functional PUT/GET internal economic system would be possible with 2^32 irvines in an analogous manner to the network conditions at launch. If all but 1 irvine are lost again, there is enough divisibility with the remaining 64 bits to still maintain near perfect functionality. This is not possible when using a decimal system from the start.
-
Doing the fixed integer math directly on the binary system is easy and not that big of a deal. If desired, a single maidsafe library crate could be linked by all sapps to make the conversions seamless and trivial. The same kind of carry-add functions are needed regardless of whether or not you have a max_val of 1e9 irvs/S or 2^32 irvs/S. Why limit the divisibility if you don’t need to?
There are no errors when keeping binary as the fundamental system. In order to have an error the results would need to differ within the same number of significant figs. They are identical to the same precision.
Beat me to it, hahaha
1 Like
Only by using rounding.
If you get 4 lots of 0.24999999 (rounds to 0.25) then the rounding shows 1.00 safecoin, but you cannot send 1 safecoin since you don’t actually have 1 full safecoin. So I agree with @fred and disagree with your statement of “no error” and no difference.
You must use decimal if you wish to claim its decimal. Errors even in the 18th decimal place will haunt you as I showed above.
You might be thinking of fixed point maths.
Hey neo! Great to see you came back from vacation.
The forum wasn’t the same without you.
I think the rounding problem in your example comes from using floating point math rather than what should happen if the accountants are doing things right with ints. This is how I see the backend using integers… assuming that you wanted to repeat the 9’s out to the 27 places of precision by using 1E9 irv/S, 1E9 tro/irv, and 1E9 ayr/tro.
4 x 0.249999999999999999 S = 0.999999999999999996 S
Fixed point math using 1E9 divs per denomination aka (Decimal Version):
0.999999999999999996 S = 999999999 irv + 999999999 tro + 999999996 ayr
The binary version has more precision, so I’ll represent it like this to point out the difference:
Fixed point math using 2^32 divs per denomination aka (Binary Version):
4294967295 irv + 4294967223 tro + 3380037450 ayr = 0.999999999999999996(08) S
Both representations are exactly the same to 27 digits of precision, both systems can be presented in the UI as a floating point 0.999x number if desired. However, the “Binary Version” is more capable/useful for the variety of reasons I posted previously.
1 Like
Without reading the thread…
I wonder that the ‘penny’ has merit for being default in so many currencies over time. Perhaps not for the Satoshi equivalent but at some order of magnitude… making it similar to the idea of a gold penny.
Perhaps for 1 safecoin could be a ‘bar’.
For the Satoshi equivalent I’d choose one ‘bit’… and perhaps many bits in a ‘nugget’?
2 Likes
Wrong
Decimal is a multiple of 10s So if using say 64 bits then we set the divs to 1x10^17 (or 10^18) divs and 0.25 is 25000000000000000 divs
And that is EXACT my laddy 
And fixed point would be over the whole, so you’d need to not split your number into 2 Binary parts using fudged fixed point. Why would you have 3 “binary denominations” anyhow. Its over complicating a balance system.
1 Like
Yes, but you didn’t say 0.25, you said 0.2499999999999999999 x 4. Regardless, I get what you mean, and know how “easy” (relative term) it works for 64bit, but I wasn’t referring to the use uint64 like in your original balance method for this discussion. My previous response was continuing the conversation from the middle part of this thread, as well what you and I talked about the quasi-infinite divisibility thread using 96 bits split into an array of 3 x uint32. Did you read the “A naming scheme and fractional denomination convention for Safecoin divisibility” from 9 days ago?
It’s ok if you don’t like it, I won’t be offended. I think it’s fun, and technically better, and more usable long term, offering the same or alternative UI and… (Sarcasm filter disengaged) I like the way the word troon sounds too. Obviously 3x32 is better than 64 because you get more bits. Who doesn’t like having more and more and more and more bits… isn’t that the SAFE philosophy?(Sarcasm filter engaged) 
I was hoping you would critique that list rather than focus on uint64 vs. uint32[3].