Topic: NXT :: descendant of Bitcoin - Updated Information - page 82. (Read 2761645 times)
Obviously, all these shitcoins get buried under BTC, NXT, Ethereum, ...
With the crazy copy launches of all kinds of alt coins. Do you think btc and nxt will be buried by them.
Do any of those coins provide any new features or anything new?
With the crazy copy launches of all kinds of alt coins. Do you think btc and nxt will be buried by them.
As was already said this problem is solved by using EPSILON.
I fear, I have to disagree.
One does not solve the problem of missing information by adding an epsilon. If I have $1000000000000000000000 and want to add $0.01, then it is $1000000000000000000000.01 and NOT $1000000000000000000000 as it would be with FP.
That is the whole issue with IEEE 754. Other approaches like fixed point (with arbitrary precision) etc. are the secure way to go at least in financial sector.
Haha, u can't do the same using integers too.
Was not saying this.
Btw. different languages have "real" integers in the sense of unlimited size. And if you want 100% security, use those fixed point with unlimited size. Nobody needs to wrap his mind how to convert an integer forth and back between its currency counterpart by dividing by 10 or so.
As was already said this problem is solved by using EPSILON.
I fear, I have to disagree.
One does not solve the problem of missing information by adding an epsilon. If I have $1000000000000000000000 and want to add $0.01, then it is $1000000000000000000000.01 and NOT $1000000000000000000000 as it would be with FP.
That is the whole issue with IEEE 754. Other approaches like fixed point (with arbitrary precision) etc. are the secure way to go at least in financial sector.
Haha, u can't do the same using integers too.
As was already said this problem is solved by using EPSILON.
I fear, I have to disagree.
One does not solve the problem of missing information by adding an epsilon. If I have $1000000000000000000000 and want to add $0.01, then it is $1000000000000000000000.01 and NOT $1000000000000000000000 as it would be with FP. In the example above, also data is missing, so that it cannot be reconstructed with 100% probability.
That is the whole issue with IEEE 754. Other approaches like fixed point (with arbitrary precision) etc. are the secure way to go at least in financial sector.
Floating point for "scientific calculations" is and always has been *perfectly fine*.
Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.
Again my simple example:
Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).
The problems are *not just rounding issues* but actually are *logic issues* (and therefore not obvious to "math" people who are only thinking about things like rounding).
It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.
Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.
Again my simple example:
Code:
#define test( v1, op, v2 ) if( v1 op v2 ) printf( #v1 " " #op " " #v2 "\n" )
#include
#include
int main( )
{
volatile double a, b, c;
char buf[ 50 ];
a = 13.06;
b = 0.54;
sprintf( buf, "%lf", a + b );
c = atof( buf );
printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );
test( c, >, 13.60 );
test( c, ==, 13.60 );
test( c, <, 13.60 );
test( a + b, >, 13.60 );
test( a + b, ==, 13.60 );
test( a + b, <, 13.60 );
return 0;
}
Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).
The problems are *not just rounding issues* but actually are *logic issues* (and therefore not obvious to "math" people who are only thinking about things like rounding).
It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.
As was already said this problem is solved by using EPSILON.
I would never dream of telling you that you had to use floating point for everything. why the need to tell me what parts of the CPU I am not allowed to use?
Don't get emotional, please.
I would be able to take this currency much more serious if it at least had a decimal place. Forget "decentralized exchange", "decentralized crack houses", "whatever", where is the god damn decimal place???
You mean like 0.0005 NXT?
Developers are working on that right now.
I would be able to take this currency much more serious if it at least had a decimal place. Forget "decentralized exchange", "decentralized crack houses", "whatever", where is the god damn decimal place???
It's here https://nxtforum.org/general-discussion/name-for-10-8-nxt/
I would be able to take this currency much more serious if it at least had a decimal place. Forget "decentralized exchange", "decentralized crack houses", "whatever", where is the god damn decimal place???
Captain Picard is implementing it as we speak.... god damn it
https://bitbucket.org/JeanLucPicard/nxt/commits/branch/feature/nqt
NQT means Nxt Quant, it allows 8 decimal places
I would be able to take this currency much more serious if it at least had a decimal place. Forget "decentralized exchange", "decentralized crack houses", "whatever", where is the god damn decimal place???
Q1 What is the error rate of representing 1/3 with int64_t vs double?
Q2 Is nodecoin a financial money application?
Q2 Is nodecoin a financial money application?
James - rounding is rounding - the accuracy is the "size of the mantissa" and the problem with a double is it has a smaller mantissa than a 64 bit integer (as it holds both mantissa and exponent in the same 64 bit space).
So for *accuracy* an "integer" is always going to be *better* than a "floating point" of the same "size".
I really don't care about nodecoin at all - so if you've used binary floating point in that code only then that is good.
Your statement that
So for *accuracy* an "integer" is always going to be *better* than a "floating point" of the same "size".
would be true if you had assurance on the dynamic range of the input numbers. However, if you have to deal with some really small values and also some relatively much larger values, then floating point wins in the average error case.Basically, if the smallest to biggest has a ratio of less than 10 or 11 bits (1024 to 2048), then using integers will make sense. however if the dynamic range is a lot bigger, say a million to 1, then that is 20 bits. In that case, you risk creating an overflow using integers or have to accept a higher error rate.
Maybe you have a way of using dynamic multipliers depending on the scale of the number, but talk about overcomplicating things and the chance for bugs. With floating point you can just go x += y, and not have to worry about scaling and the error rate is decent.
There should not be a ban on using floating point. I would never dream of telling you that you had to use floating point for everything. why the need to tell me what parts of the CPU I am not allowed to use?
James
Edit: Using satoshi as least common denominator: 1/3 -> .33333333 so, error rate using integer is .000000003333333...
that is much worse than errors with doubles, which goes out to around 14 digits +/- .000000000000001
Q1 What is the error rate of representing 1/3 with int64_t vs double?
Q2 Is nodecoin a financial money application?
Q2 Is nodecoin a financial money application?
James - rounding is rounding - the accuracy is the "size of the mantissa" and the problem with a double is it has a smaller mantissa than a 64 bit integer (as it holds both mantissa and exponent in the same 64 bit space).
So for *accuracy* an "integer" is always going to be *better* than a "floating point" of the same "size".
I really don't care about nodecoin at all - so if you've used binary floating point in that code only then that is good.
Floating point for "scientific calculations" is and always has been *perfectly fine*.
Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.
Again my simple example:
Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).
The problems are *not just rounding issues* but actually are *logic issues* (and therefore not obvious to "math" people who are only thinking about things like rounding).
It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.
Q1 What is the error rate of representing 1/3 with int64_t vs double?Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.
Again my simple example:
Code:
#define test( v1, op, v2 ) if( v1 op v2 ) printf( #v1 " " #op " " #v2 "\n" )
#include
#include
int main( )
{
volatile double a, b, c;
char buf[ 50 ];
a = 13.06;
b = 0.54;
sprintf( buf, "%lf", a + b );
c = atof( buf );
printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );
test( c, >, 13.60 );
test( c, ==, 13.60 );
test( c, <, 13.60 );
test( a + b, >, 13.60 );
test( a + b, ==, 13.60 );
test( a + b, <, 13.60 );
return 0;
}
#include
#include
int main( )
{
volatile double a, b, c;
char buf[ 50 ];
a = 13.06;
b = 0.54;
sprintf( buf, "%lf", a + b );
c = atof( buf );
printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );
test( c, >, 13.60 );
test( c, ==, 13.60 );
test( c, <, 13.60 );
test( a + b, >, 13.60 );
test( a + b, ==, 13.60 );
test( a + b, <, 13.60 );
return 0;
}
Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).
The problems are *not just rounding issues* but actually are *logic issues* (and therefore not obvious to "math" people who are only thinking about things like rounding).
It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.
Q2 Is nodecoin a financial money application?
Floating point for "scientific calculations" is and always has been *perfectly fine*.
Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.
Again my simple example:
Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).
The problems are *not just rounding issues* but actually are *logic issues*.
It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.
Your example is shocking and makes people want to forbid using floating point.Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.
Again my simple example:
Code:
#define test( v1, op, v2 ) if( v1 op v2 ) printf( #v1 " " #op " " #v2 "\n" )
#include
#include
int main( )
{
volatile double a, b, c;
char buf[ 50 ];
a = 13.06;
b = 0.54;
sprintf( buf, "%lf", a + b );
c = atof( buf );
printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );
test( c, >, 13.60 );
test( c, ==, 13.60 );
test( c, <, 13.60 );
test( a + b, >, 13.60 );
test( a + b, ==, 13.60 );
test( a + b, <, 13.60 );
return 0;
}
#include
#include
int main( )
{
volatile double a, b, c;
char buf[ 50 ];
a = 13.06;
b = 0.54;
sprintf( buf, "%lf", a + b );
c = atof( buf );
printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );
test( c, >, 13.60 );
test( c, ==, 13.60 );
test( c, <, 13.60 );
test( a + b, >, 13.60 );
test( a + b, ==, 13.60 );
test( a + b, <, 13.60 );
return 0;
}
Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).
The problems are *not just rounding issues* but actually are *logic issues*.
It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.
Not comparing against epsilons or doing things like
if ( fabs(x) < SMALLVALL ) for comparing to zero is not a logic issue, that is a coding bug that a code review would find.
In any case, if summing nodecoin allocations ends up going above the payout threshold (or not) one block ahead (or behind), the world wont end.
If you feel so strongly about this, you are free to rewrite the nodecoin pool allocation however you want as I prefer to use the CPU's built in floating point vs. software libraries to get better approx than 64 bit floats gets.
I just dont see the horrible things that could happen due to:
nxtacct->dnodecoins += nxtacct->dcurrent_nodecoins;
nxtacct->dcurrent_nodecoins = ((blockrate * ip->nodeshares) / sum);
ip->nodeshares = 0;
dsum += nxtacct->dcurrent_nodecoins;
if ( nxtacct->dnodecoins >= NODECOIN_MINPAYOUT )
{
satoshis = (int64_t)nxtacct->dnodecoins * SATOSHIDEN;
transfer_txid = issue_transferAsset(mp->NXTACCTSECRET,nxtacct->NXTaddr,NODECOIN,satoshis/SATOSHIDEN,MIN_NXTFEE,1440,0);
if ( transfer_txid != 0 )
{
printf("PAYOUT txid.%lx NXT.%s <- %.8f nodecoins\n",(long)transfer_txid,nxtacct->NXTaddr,(double)satoshis/SATOSHIDEN);
nxtacct->nodecoins_sent += satoshis;
nxtacct->dnodecoins -= (int64_t)nxtacct->dnodecoins;
}
}
The variables starting with "d" are doubles. The super dangerous usage of floating point adds each blocks earned nodecoins to "dnodecoins". If it compares as above the NODECOIN_MINPAYOUT threshold, it pays out and deducts what was paid out. If it miscompares, then it will payout the next block
Also, using data from my use case, using doubles was more accurate than using ints, but maybe I just dont know how to program. Please tell me what is wrong with my usage and please do not bring up hardcat or demo programs that dont apply to this use case
James
Floating point for "scientific calculations" is and always has been *perfectly fine*.
Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.
Again my simple example:
Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).
The problems are *not just rounding issues* but actually are *logic issues* (and therefore not obvious to "math" people who are only thinking about things like rounding).
It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.
Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.
Again my simple example:
Code:
#define test( v1, op, v2 ) if( v1 op v2 ) printf( #v1 " " #op " " #v2 "\n" )
#include
#include
int main( )
{
volatile double a, b, c;
char buf[ 50 ];
a = 13.06;
b = 0.54;
sprintf( buf, "%lf", a + b );
c = atof( buf );
printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );
test( c, >, 13.60 );
test( c, ==, 13.60 );
test( c, <, 13.60 );
test( a + b, >, 13.60 );
test( a + b, ==, 13.60 );
test( a + b, <, 13.60 );
return 0;
}
#include
#include
int main( )
{
volatile double a, b, c;
char buf[ 50 ];
a = 13.06;
b = 0.54;
sprintf( buf, "%lf", a + b );
c = atof( buf );
printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );
test( c, >, 13.60 );
test( c, ==, 13.60 );
test( c, <, 13.60 );
test( a + b, >, 13.60 );
test( a + b, ==, 13.60 );
test( a + b, <, 13.60 );
return 0;
}
Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).
The problems are *not just rounding issues* but actually are *logic issues* (and therefore not obvious to "math" people who are only thinking about things like rounding).
It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.
Amazing to see how Nxt is progressing! Good job every one that is responsible for the success!
I do have a question about the decentralized exchange. As the day draws closer that its getting released, its time to learn the exact details how it works.
As a big fan of Nxt and of CryptogenicBullion ( CGB), I am highly interested to get CGB to be one of the first assets trading on the Nxt system
Is there any documentation available on how to create and maintain an asset, or how the whole process works?
Any help would be greatly appreciated!
If CGB is a bitcoind fork and supports multisig, I could add it to multigatewayI do have a question about the decentralized exchange. As the day draws closer that its getting released, its time to learn the exact details how it works.
As a big fan of Nxt and of CryptogenicBullion ( CGB), I am highly interested to get CGB to be one of the first assets trading on the Nxt system
Is there any documentation available on how to create and maintain an asset, or how the whole process works?
Any help would be greatly appreciated!
Then there would be a seamless way of depositing and withdrawing CGB into NXT AE and back out to CGB wallets
The deposited CGB would be kept in multisig accts that no single server can unlock, all three need to reach consensus on all withdraws and all balances are publicly viewable so there is no guessing as to the solvency.
James
Did a quick look-see and it appears to be a fork of Peercoin. Also, from https://github.com/cryptogenicbonds/CGB/blob/master/src/script.h
Quote
enum txnouttype
{
TX_NONSTANDARD,
// 'standard' transaction types:
TX_PUBKEY,
TX_PUBKEYHASH,
TX_SCRIPTHASH,
TX_MULTISIG,
};
{
TX_NONSTANDARD,
// 'standard' transaction types:
TX_PUBKEY,
TX_PUBKEYHASH,
TX_SCRIPTHASH,
TX_MULTISIG,
};
That would be awesome James! And as xyzzyx already pointed out, CGB is a fork of Peercoin (though with some exceptional features aimed at investors
) and to my knowledge supports multisig.If you could add it to your multigateway, that would be marvelous! In case you need any tech info/support, you can PM "Artiface" the lead coder or just drop in on the official CGB thread here .
Is there already any ETA when your gateway will be ready to use?
Once CGB is exchangeable on the gateway, I would be more then happy to make a donation to show my appreciation
https://nxtforum.org/multigateway-(third-party)/multigateway-beta-test-signup/ is the signup for beta testers
https://nxtforum.org/multigateway-(third-party)/multigateway-status-reports/ is where I post regular status updates
James
Just want to give you a heads up, I spoke with the lead coder of CryptogenicBullion and he is currently reviewing the CGB code and evaluating what can be done in regards with multisig. He will contact you sometime soon for discussion.
Again, thanks for your support!
I am getting close to release candidate for multigateway
I would like somebody that is fluent in C and familiar with bitcoind to do a code review
James
great. I would like somebody that is fluent in C and familiar with bitcoind to do a code review
James
Anyone know if BCNext will give a contract to another great developer after April 5?
https://bitcointalksearch.org/topic/transparent-mining-3-or-what-way-to-choose-553205
I guess BCNext just left Nxt in our hands.If we want to do something,we just do it.He wont hire anyone.
Jump to: