The proposal in the “core” data structures is to have 2 x u32 to store the whole amount and the fractional amount as a decimal. This is instead of storing it as a u64 and treat it as fixed point
struct Coin {
units: u32,
parts: u32,
}
Sorry then my bad.
Hmhmm - while I may just mention… Not long ago I worked with some pieces of code that spit out a some 64bit numbers as 2x32 bit… That’s just super annoying and all I do is merging them again and again +work with the 64bit number… Because looking at them as 32bit parts doesn’t make sense…
So I don’t really care as long as the interface is how I want it and you think it won’t mean trouble for maintenance on your side … But I think neo has a point and if they are only useful together I don’t really see a motivation to split them…
From a pure observation it seems to me like 64bit is more clean, simple and easier to work with than 2x32 bit.
I like it alot, simple and clean!
Four quintillion ,two hundred ninety four quadrillion ,nine hundred sixty seven trillion ,two hundred ninety six billion nanoSafeCoin.
Maybe when the 2 wasted bits cause us to be in trouble with divisibility it’s time to upgrade to something else anyway 
… And the problem is not the low precision…
I think someone mentioned overengineering in another thread (@opacey?). If this split structure or not debate isn’t emblematic of it, I don’t know what is. One is simple and practical, and many people with real life experience of pain have now chimed in with several examples. Yet, you refuse the feedback. Why? Meanwhile, only people in the community actually are pushing and saying something.
This isn’t how you move fast. Think of how much time has been wasted on this simple matter (and potentially will be in the future if not properly addressed).
I’m not sure the situation is so grave 
Safecoin is for a later time, nothing has been decided, nothing has been coded, no time got wasted.
Don’t forget the main reason we don’t get as much feedback as you’d like is that the team is busy working on stuff that’s necessary to get to where this subject can start to matter.
That’s how you can have divisibility to the billionth while maintaining the original 2^32 safecoins, all within 64 bits.
I don’t get what kind of conversion would happen “inside the core”:
All bitcoin software works with satoshis, but they got lucky since the largest value (2.1e15) can be represented on just 51 bits, which means even JavaScript can handle it.
The conversion from wrapper types (like the NanoCoin struct) to an actual integer.
https://forum.autonomi.community/t/rfc-57-safecoin-revised/28660/93
I’m not technically minded enough to know what the right way is here, but it is clear after reading through and looking at the hearted comments which side of this the community is on – Keep It Simple Stupid (KISS principle).
I would like to add that any long term token hodler is going to fully understand what’s going on if u64 and not u32+u32 … the ones who wouldn’t understand left the project long ago.
If we are aiming to be a new global currency - and I think it’s foolish to underestimate this possibility, then we need to align our monetary system practices with those of contemporary financial programmers and not attempt anything more complicated than is required.
This is all that is required to satisfy any and all hodlers:
IMO, @anon86652309 you are simply overthinking it.
micros might get us a long way.
Please expand more on IEEE doubles 53bit and how that could affect things because that sound like it could be something important. I looked it up on wikipedia but I don’t know enough about it to reach any form of conclusion.
Doubles can represent all integers up to 2^53 exactly, but they will start introducing rounding errors above that (first, we lose odd numbers, then those not divisible by 4, then 8, and so on).
Moreover, the set of non-integer numbers that can be represented by doubles does not coincide with the set of numbers we use for prices, that is, in base 10. For example, something as simple as 0.1 is impossible with doubles—we get a number “close enough to, but not quite” 0.1 instead. This is why we use fixed point numbers (that is, integers divided by a fixed power of 10) whenever we need exact calculations in base 10.
As @JoeSmithJr said
But to reiterate you are suggesting what excel did and screwed up financial calculations and had to introduce round(), roundup(), rounddown() in order to allow real financial calculations to be done. Excel went against what was 3 decades of common sense fixed point for financial and we today still shun excel for serious financial applications, like banking etc.
Floating point for financial is crazy when you can represent the absolute exact value as a u64 or u128 integer.
Integer maths/representation
Fixed point decimals are not necessarily more exact than binary floats though. For exchanging between different currencies, both are equally imprecise because division often results in rational numbers that can’t be represented exactly in either or both of base 2 and 10. However, we use base 10 for purposes like finance so we’re willing to accept (and are prepared to deal with) rounding errors in that result of using base 10 but not those that are the results of base 2.
But the effects are well know. Introducing float makes the effects worse, that was my point.
The exact also was for the point at hand and that is nanosafecoin.
Some relevant bitcoin history with uncanny similarity to the conversation here about divisibility (bitcoin has always been integer math)
https://en.bitcoin.it/wiki/Satoshi_(unit)
How did “Satoshi” become the name of the base unit
Bitcoin source from November 2008
Finney, Satoshi, and I discussed how divisible a Bitcoin ought to be. Satoshi had already more or less decided on a 50-coin per block payout with halving every so often to add up to a 21M coin supply. Finney made the point that people should never need any currency division smaller than a US penny, and then somebody (I forget who) consulted some oracle somewhere like maybe Wikipedia and figured out what the entire world’s M1 money supply at that time was.
We debated for a while about which measure of money Bitcoin most closely approximated; but M2, M3, and so on are all for debt-based currencies, so I agreed with Finney that M1 was probably the best measure.
21Million, times 10^8 subdivisions, meant that even if the whole word’s money supply were replaced by the 21 million bitcoins the smallest unit (we weren’t calling them Satoshis yet) would still be worth a bit less than a penny, so no matter what happened – even if the entire economy of planet earth were measured in Bitcoin – it would never inconvenience people by being too large a unit for convenience.
Can anyone link to software that has a dollars/cents kind of struct (ie split the same as units/parts)? I don’t know of any.
Just to be sure (even though I’m confident everyone in the thread already knows) I want to explicity state that IEEE doubles are not and never have been and never will be proposed or used for safecoin. Floating point numbers do not belong in the topic of ‘money’ (other than clarification of why they’re not used!)
The whole of your post is why I cannot understand why we are even having this discussion. We have history that tells us and @anon86652309 what is the best way at this time to go.
I have some experience of working in fintech and I have never seen this. I suspect suggesting it would not be well received either.
I have seen 3 systems in use - integer (long), fixed point (BigDecimal) and string (non-fintech, but treated as integer). I have never seen split unit/parts.
Agreed. I suspect the wider crypto community will also find it strange, at best. At worse, they will find it laughable and dismiss the rest of the project on its merit.
I don’t mean to sound unkind, but trolls will have a field day. It is also completely unnecessary to go against what history has taught us.
And I’d like to reiterate that in all my responses, I do not think anyone, especially @anon86652309 are anything but very smart and capable people doing a better job than I could here. But when something like this comes up then my past experience tells me its very wrong.
Could I just add, this RFC is not @anon86652309 alone, it has gone through internal pre-rfc work and debate. So is the whole maidsafe team. In saying that @anon86652309 is shepherding this through (so do keep him involved as you are) the RFC process so we can get version 1 in place. I think this is exactly the kin dof thing we depend on the wider community for (this unit versus a u64 etc.) and it is to me very enlightening. I hope nobody feels ignored and everyone included, but this is obviously something that is important and needs to be resolved. I think @neo @Traktion and others have experience here in finance that many of us do not have so thank you very much. I also like the history of bitcoin that @mav has posted is very compelling.
In short, I like many others are following this part of the discussion really closely and I always go for simplicity where possible, so am liking the idea of tiny parts of a safecoin being considered a safecoin, kinda like satoshi’s in bitcoin. Brilliant community and superb feedback so far.
Yea, we could be generic and call them nanos, or safenanos, or Daves, or safties, or just nanosafe
