[PoS+PoW] eXocoin [EXO]-gen 2.0- dev. from scratch! Give-Away | Open Beta

[Eadeqa]

Looking forward to test the new version!  

An advice from an old c++ coder:

bugfix: double-round function was not accurate enough for one comparision

Don't use floating point in a financial application! Nasty round and compare bugs ahead!  

Use a long or longlong and do integer division to get to the decimals.

Yes that might be a good idea;-) Right now it will round it to 12 decimals accuracy and is working as well.... but we will consider changing that.

Make that priority, please. Before the release date. Floating points should not be used in financial applications.

[ThomasZ80]

...  sent 3333 EXO right back!!!     

Got it!  

EXOk3Z2aewR5asfdpT6qCFcO5gxDtTNDyw4tdbhg

[eXo_coin]

...  sent 3333 EXO right back!!!     

Got it!  

EXOk3Z2aewR5asfdpT6qCFcO5gxDtTNDyw4tdbhg

network looks good right now ... lets wait some more hours!

I was very generous transfering 0.1 EXO

[wizzardTim]

PLease send me some for test EXO6ZqUDk8rexbs4uPztfK69WKUYPATSSrRndbgm

[wizzardTim]

...  sent 3333 EXO right back!!!     

Got it!  

EXOk3Z2aewR5asfdpT6qCFcO5gxDtTNDyw4tdbhg

sent you some

[Fonzarelli]

I just was messing around with 666.666 EXO 

However, client sent 666.667

So I created EXO out of nowhere 

[ThomasZ80]

I was very generous transfering 0.1 EXO

WOW! Thanks a lot.  
Got it.  

[eXo_coin]

PLease send me some for test EXO6ZqUDk8rexbs4uPztfK69WKUYPATSSrRndbgm

send: TX55935C7CA5900A81108DF73336EDA8E363A65D8AC35B46D29428F8DC17E6954C



btw: mining will hopefully start at block 100 automatically (watch block explorer mining value or mining tab)

[wizzardTim]

got some too 

[ThomasZ80]

...  sent 3333 EXO right back!!!     

Got it!  

EXOk3Z2aewR5asfdpT6qCFcO5gxDtTNDyw4tdbhg

sent you some

Just got 333.33.

[Fonzarelli]

Does the bug reply section already work?

[eXo_coin]

I just was messing around with 666.666 EXO  

However, client sent 666.667

So I created EXO out of nowhere  

Yup...  got it!    

The eXominer seems to be working too...  but I have a question...  why does it stop hashing away in order to submit to parent?    

that is the key innovation regarding our mining system: if you find a system you submit it and therafter up to the start of the next block your miner will idle. ->Saving you energy costs! The faster you find a result the more EXO you'll get and the less energy cost you will have (procentually regarding hashpower).
As stated, you'll get hopefully some mining transactions after block 100 has been reached

[timmyd]

Im liking what im reading here 

[mikesbmw]

I just was messing around with 666.666 EXO  

However, client sent 666.667

So I created EXO out of nowhere  

What's causing this? Is this some floating point bug?
Do you use floating point at all?

[chinnuperiya]

Looking forward to test the new version!  

An advice from an old c++ coder:

bugfix: double-round function was not accurate enough for one comparision

Don't use floating point in a financial application! Nasty round and compare bugs ahead!  

Use a long or longlong and do integer division to get to the decimals.

Yes that might be a good idea;-) Right now it will round it to 12 decimals accuracy and is working as well.... but we will consider changing that.

Make that priority, please. Before the release date. Floating points should not be used in financial applications.

yes. I have had nightmares working with double in financial modelling. Please change it to long before the final release

[Fonzarelli]

I just was messing around with 666.666 EXO  

However, client sent 666.667

So I created EXO out of nowhere  

What's causing this? Is this some floating point bug?
Do you use floating point at all?

I sent about 666.666666666666666666 in the form
Exo-client sent 666.667 so he round to 3 decimals.

I dont know how is that so. But actually 666.667 left the wallet. So no "problem" at all, just rounding issue

[ATC]

Looking forward to test the new version!  

An advice from an old c++ coder:

bugfix: double-round function was not accurate enough for one comparision

Don't use floating point in a financial application! Nasty round and compare bugs ahead!  

Use a long or longlong and do integer division to get to the decimals.

Yes that might be a good idea;-) Right now it will round it to 12 decimals accuracy and is working as well.... but we will consider changing that.

Make that priority, please. Before the release date. Floating points should not be used in financial applications.

+1

Make it priority! Only integer in finance.

BTW, anyone with address in the recent posts will get 8888.88 exo.

[eXo_coin]

hm strange.. when searching for EXORGxHC1e1h2Dq6QgNpnhy32gTbh2BC2gFycmgc in the block explorer the 666.667 does not appear. The other address to that transaction is displaying the amount.
That will be investigated - as well as the rounding of 667. But that are just minor bugs. If all nodes survive the next 12 hours then we are happy

It is not a problem with using doubles at all. They have a precision of 15 decimals, we capped it at 12. So the 12th decimal will be a rounded value but not the third one like here. But let us check whats the issue here.
Doubles are an issue in comparisions if they are not properly addressed. But with capping/rounding at 12th decimal there should not be an issue anyway. I, personally, never got in trouble with this processing of data but correct me if I am wrong. We could use unsigned long long anyway for V0.6


Right now after ~7 hours running nodes (some ~10) all are still in sync and fully functional. That's the all-time best message here I guess ;-) No crashes or asyncs yet. Crossing fingers for the next hours...




#edit

I just was messing around with 666.666 EXO  

However, client sent 666.667

So I created EXO out of nowhere  

What's causing this? Is this some floating point bug?
Do you use floating point at all?

I sent about 666.666666666666666666 in the form
Exo-client sent 666.667 so he round to 3 decimals.

I dont know how is that so. But actually 666.667 left the wallet. So no "problem" at all, just rounding issue

Ah ok exokk most possibly capped the counting decimals of transactions within the GUI interface to 3 decimals and rounds it properly. I'll ask him/check it and will increase it

[griffinriz]

Received email 

[chinnuperiya]

please send me some test EXOs. will send them back with simple interest of 100% 

EXOyahgZ5Csz31ctmnK22arfAUUWAaZRs1gxdbhd