Subdividing SafeCoin

[Seneca]

Perhaps I’m missing something, but the subdividing of SafeCoin appears like a real hassle to me. From the whitepaper:

“This format allows the tokens to be split into 2^248 parts if required. The splitting process will only allow the token (or subdivided token) to be bisected, so e.g. quartering a token would need to be done in 2 steps.”

So 0,5 SafeCoin is one subdivision, 0,25 are two subdivisions, 0,125 three, 0,0625 four, 0,03125 five, 0,015625 six, 0,0078125 seven, 0,00390625 eight, etc.

How would you get 0,30 SafeCoin? 0,25 is two subdivisions, we need to add 0,05 to that to get 0,30. Adding a fifth subdivion plus a sixth gets us to 0,046875. If we add the eighth subdivision to that, we get 0,046875 + 0,00390625 = 0,05078125. That’s just too much, so we need to scratch the eighth subdivision and subdivide even further to add a smaller number.

Is there some computational trick to let a computer calculate and manage all the subdivided SafeCoins very quickly?

[happybeing]

Division by two and powers of two is extremely efficient because of the binary representation of values in a computer, and this is no doubt why the scheme has been chosen. I don’t know the algorithm for the process you illustrated, but expect there is something that will handle it extremely efficiently. I think this is in the realm of numerical analysis if you want to search!

[Seneca]

@happybeing

Division by two and powers of two is extremely efficient because of the binary representation of values in a computer,

Aye, like bitshifting to multiply or divide by two. But according to the whitepaper: “When splitting a token, only the name changes; all other parts are copied to the new subdivisions.”

Since there can be 2^248 subdivisions, there may be tons and tons of copies required to represent values like 0.37495 SafeCoin? Even if the calculation of which subdivisions will be required is very fast, copying and signing all those subdivisions seems like a demanding process to me.

[Seneca]

I may have got it.

If the third field is 2 bits long, and the fifth field has as value 3, then that record is 0.75 SafeCoin, since 3 in binary is 11. If the bit length would 3 and the value 3, it would be 011, which is 0.375.

That means there is no need for a copy of a SafeCoin record for every subdivision if those subdivisions belong to the same wallet. There can simply be one SafeCoin record that has multiple subdivisions in it.

I’m still curious about the algorithm with which you can find the required divisions for a given value. The most obvious way would be a loop up to 248 times, but surely there is something more efficient?

EDIT: Also, am I correct in thinking that 248 subdivisions allows for values with 72 decimals of precision? (Bitcoin has 8, hehe)

[happybeing]

My “intuitive knowing” says “sounds right”, but I’m unable to say “for sure”

[digipl]

We speak about this:

Division in Safecoin

One think I don’t like about the safecoin is the binary division. With this division you have the following numbers: 0.5 0.25 0.125 0.0625 0,03125 0.015625 0.0078125 0.00390625 … until 2^248 divisions But in the real world you use decimal number X.X, X.XX, X.XXX,… so if you need to made a transfer with decimals probably you need to divide your safecoin a lot of times only to reach the exact number generating a lot of new safecoin files. Of course the binary division is easy in the co…

[Seneca]

@digipl

We speak about this:

I see. Well then, I have some new insight:

@digipl

if you need to made a transfer with decimals probably you need to divide your safecoin a lot of times only to reach the exact number generating a lot of new safecoin files.

Division would be handled by the computer to reach a desired value, it wouldn’t be a manual process.

[quote=“digipl, post:3, topic:645”]
for example to pay 0.1 safecoin close to 8 decimals (you cannot reach the exact number) you need the following:A7+A8+A11+A12+A15+A16+A19+A20+A23+A24+A27+A28 = 0.0999999940395355In each AX, X is the number of division.[/quote]

The precision is still insanely high if you continue up to A248. It really matters nothing if say the 70th decimal is rounded up from 9 to finally get 0.1. It’s utterly negligible, even if one SafeCoin would be worth a million dollars.

@digipl

In this case you need to generate 56 new safecoin files and you send 12 in the transfer.

As I explained in my previous post, that’s not the case. Only one more copy needs to be made. Also, the SafeCoin data is not transferred on division, it’s managed by the same trusted group of vaults:

“(…) force all subdivisions of a given coin token the same trusted group of vaults to eliminate the need for network traffic when handling such subdivisions.”

The copy only has to signed by the new owner.

[fergish]

I envision that subdivisions will happen when the value vs smallest likely-needed amount gets uncomfortable.

I think trying to get the safecoin subunit to exactly match decimal divisions is unnecessary–and actually would never be possible with exactitude anyway, regardless of the granularity of safecoin division.

An automatic rounding will be necessary in conversion in any case, so we’ll just have to go with that. When the value gets to the point where the current subdivision is not small enough to accommodate rounding without pain (or when it starts to approach that) then is the time to subdivide again.

[Seneca]

I don’t really see an objection to rounding to maximum precision from the start, it’s only 248+8 bits that need to be changed. Even if it would need to loop 248 times to gather all the required divisions for maximum precision, it would only take the user’s local client mere moments to do that.

[fergish]

@Seneca

I don’t really see an objection to rounding to maximum precision from the start,

I would tend to agree, but I think that that is a level of action that the devs don’t really want to engage in till after the network is functioning, and the value of safecoin indicates how far it should go.