` is also commonly called a backtick. I've even seen it called that by non-unix/non-technical people to disambiguate the thing on the keyboard and the thing in ASCII from a "proper" grave. In fact, I'm not sure that it is even technically a "grave" when it isn't attached to a vowel.
Similar problems come up with quotation marks. ASCII has "single quote" and "double quote", but again, they aren't "proper", so some people call those versions by those names to distinguish them from actual real "quotation marks".
Topic: Separators after the decimal place. (Read 1636 times)
I sometimes add a space to help make the number more readable. Like the price for a share of S.MPOE is something like 0.00072828 bitcoins, you could write that as 0.000 728 28 to make it more readable. The problem with that is the space makes it hard to know where the number ends. An alternative would be to use ` (on my keyboard it is on the same key as the tilde, ~, but I never use it for anything), so the price would be 0.000`728`28 which is also more readable than having no separators. What is that mark even called?
` is a grave
´ is an acute
I sometimes add a space to help make the number more readable. Like the price for a share of S.MPOE is something like 0.00072828 bitcoins, you could write that as 0.000 728 28 to make it more readable. The problem with that is the space makes it hard to know where the number ends. An alternative would be to use ` (on my keyboard it is on the same key as the tilde, ~, but I never use it for anything), so the price would be 0.000`728`28 which is also more readable than having no separators. What is that mark even called?
If you want to have lots of precision in your database or whatever, you could write numbers like 11`258`124.000`999`94 using the tick mark before and after the decimal separator.
If you want to have lots of precision in your database or whatever, you could write numbers like 11`258`124.000`999`94 using the tick mark before and after the decimal separator.
How to spot new members without looking at their post count or signup date, number 718:
Refers to bitcoin address in signature with a "witty" remark that loose change should be sent there.
Refers to bitcoin address in signature with a "witty" remark that loose change should be sent there.
Nah, I still do that. Worked out pretty well so far too.
It's much preferred to the other option of large font, colored spammy advertisements that new members are rolling in with sometimes.
How to spot new members without looking at their post count or signup date, number 718:
Refers to bitcoin address in signature with a "witty" remark that loose change should be sent there.
Refers to bitcoin address in signature with a "witty" remark that loose change should be sent there.
Nah, I still do that. Worked out pretty well so far too.
How to spot new members without looking at their post count or signup date, number 718:
Refers to bitcoin address in signature with a "witty" remark that loose change should be sent there.
Quoting http://en.wikipedia.org/wiki/ISO_31-0#Numbers:
Refers to bitcoin address in signature with a "witty" remark that loose change should be sent there.
Quoting http://en.wikipedia.org/wiki/ISO_31-0#Numbers:
Quote
Numbers consisting of long sequences of digits can be made more readable by separating them into groups, preferably groups of three, separated by a small space. For this reason, ISO 31-0 specifies that such groups of digits should never be separated by a comma or point, as these are reserved for use as the decimal sign.
It is time people start using thousand separators (,) after the decimal place.
Actually, the "thousand seperator" is a "." and the "decimal seperator" is a "," around here... 1.000,001 is perfectly valid for 1000 + 0.001.
When was the last time you saw a car priced down to cents? A house down to single dollars?
This (using seperators right from the decimal seperator) is not part of any standard I know of, please link a ISO or DIN standard that one can adhere to in this matter and don't invent your own stuff.
I don't claim there is an ISO standard. Can you find the one that says it must be for the whole number part? I have decided this is helpful in reading numbers. But I have to agree that perhaps normally such precision is not needed, you may send the bitcoin amounts under 0.001 to the address in my sig.
> separators after the decimal place.
Don't tell me you named yourself after that idea....
Don't tell me you named yourself after that idea....
It is time people start using thousand separators (,) after the decimal place.
Actually, the "thousand seperator" is a "." and the "decimal seperator" is a "," around here... 1.000,001 is perfectly valid for 1000 + 0.001.
When was the last time you saw a car priced down to cents? A house down to single dollars?
This (using seperators right from the decimal seperator) is not part of any standard I know of, please link a ISO or DIN standard that one can adhere to in this matter and don't invent your own stuff.
Why use digits that provide no useful meaning. Do you routinely price things in 1/10,000th of a US penny?
At current exchange rates 0.1 mBTC is worth 0.12 US cents. Do you really need more precision than that. I mean would you expect a retailer in a USD store to price something as $123.45678912 or maybe they would just round it to the nearest cent ($123.46).
In your example the following values have the following precision of purchasing power.
In most examples even the 1 mBTC precision = ~$0.11 is sufficient. A merchant for example is unlikely to have a profit margin where rounding with $0.06 gain or loss on a $110 product materially affects balances. For all other scenarios 0.1 mBTC is probably sufficient. The rest of the decimal
places simply add noise without any value no matter how you write them.
So as a merchant I would just write it as 1.001 BTC or 1,0001 mBTC.
As a practical example I don't find constraining my prices to 1mBTC precision to be a problem.
See here: https://bitcointalksearch.org/topic/sold-lot-of-18-1oz-canadian-silver-maple-leaf-rounds-9999-fine-227532
Price widget.
Is that hard to read or understand? I don't feel that adding more digits materially changes things. If the price keeps rising I could see going to 4 digits (0.1 mBTC precision) at around the $200 exchange rate but not 5,6,7, or 8 digits.
I really think prices will move to mBTC because people do generally dislike extended decimal places. If you want to get some marketing effect maybe "On Sale Only 999 mBTC. Buy Now!".
At current exchange rates 0.1 mBTC is worth 0.12 US cents. Do you really need more precision than that. I mean would you expect a retailer in a USD store to price something as $123.45678912 or maybe they would just round it to the nearest cent ($123.46).
In your example the following values have the following precision of purchasing power.
Code:
1.00143781 = $110.85916557
1.0014378 = $110.85916446
1.001437 = $110.85907590
1.00143 = $110.85830100
1.0014 = $110.85498000
1.001 = $110.81070000
1.0014378 = $110.85916446
1.001437 = $110.85907590
1.00143 = $110.85830100
1.0014 = $110.85498000
1.001 = $110.81070000
In most examples even the 1 mBTC precision = ~$0.11 is sufficient. A merchant for example is unlikely to have a profit margin where rounding with $0.06 gain or loss on a $110 product materially affects balances. For all other scenarios 0.1 mBTC is probably sufficient. The rest of the decimal
places simply add noise without any value no matter how you write them.
So as a merchant I would just write it as 1.001 BTC or 1,0001 mBTC.
As a practical example I don't find constraining my prices to 1mBTC precision to be a problem.
See here: https://bitcointalksearch.org/topic/sold-lot-of-18-1oz-canadian-silver-maple-leaf-rounds-9999-fine-227532
Price widget.
Is that hard to read or understand? I don't feel that adding more digits materially changes things. If the price keeps rising I could see going to 4 digits (0.1 mBTC precision) at around the $200 exchange rate but not 5,6,7, or 8 digits.I really think prices will move to mBTC because people do generally dislike extended decimal places. If you want to get some marketing effect maybe "On Sale Only 999 mBTC. Buy Now!".
You can just use satoshis and you won't have to worry about decimal points.
It is time people start using thousand separators (,) after the decimal place.
I love when people don't ask what the community thinks but instead states that 'It is time people start doing X' I get where the OP is coming from. 0.00005340 is kinda hard to read, but then again 0.000,053,40 kinda opens up a whole new can of worms.
I think that the push to adopt mBTC as the standard unit of currency is a better solution that causes less extra confusion. 0.05340 is a lot easer to understand, you can clearly see that 0.05 is about a 20th, 5% of the value of one unit of the currency, it's easier to understand than either 0.00005340 or 0.000,053,40 in my opinion.
So I think we should go with that.
mBTC!
I think that the push to adopt mBTC as the standard unit of currency is a better solution that causes less extra confusion. 0.05340 is a lot easer to understand, you can clearly see that 0.05 is about a 20th, 5% of the value of one unit of the currency, it's easier to understand than either 0.00005340 or 0.000,053,40 in my opinion.
So I think we should go with that.
mBTC!
Genereally speaking, Maybe we are just not used to decimals going so far. Maybe its nicer to say something like
42 BTC, 231 mBTC, and 230 uBTC. Like dollars and cents.
I get where the OP is coming from. 0.00005340 is kinda hard to read, but then again 0.000,053,40 kinda opens up a whole new can of worms.
I think that the push to adopt mBTC as the standard unit of currency is a better solution that causes less extra confusion. 0.05340 is a lot easer to understand, you can clearly see that 0.05 is about a 20th, 5% of the value of one unit of the currency, it's easier to understand than either 0.00005340 or 0.000,053,40 in my opinion.
So I think we should go with that.
mBTC!
I think that the push to adopt mBTC as the standard unit of currency is a better solution that causes less extra confusion. 0.05340 is a lot easer to understand, you can clearly see that 0.05 is about a 20th, 5% of the value of one unit of the currency, it's easier to understand than either 0.00005340 or 0.000,053,40 in my opinion.
So I think we should go with that.
mBTC!
Two common solutions are suffixes (m-, u-, n-) and spaces ( 0.00001 -> 0.000 01 ).
Even in cultures that use arabic numerals, the radix designator is not universally standardized. Plenty of people would have written my example as 0,000 01, and it gets worse if you also have a bunch of digits to the left.
Even in cultures that use arabic numerals, the radix designator is not universally standardized. Plenty of people would have written my example as 0,000 01, and it gets worse if you also have a bunch of digits to the left.
In Argentina they use dots for separators and commas for decimal points. You can set whatever your convention you want, the software should read the locale preferences and use those.
Code:
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace std;
# reads a number with thousand separators in it and one character that the value is put into v
# the last character read is left in c. The first character read in is c after that
# characters are read in from in.
template void read_with_commas(istream& in, fp_type & v, char & c) {
int sign = 1;
if (c == '-') {
sign = -1;
c = in.get();
}
v = 0.0;
while (c != '.') {
if (c != ',') {
if (isdigit(c)) {
v *= 10;
v += (c - '0');
} else {
return;
}
}
c = in.get();
}
if (c == '.') {
fp_type order = 1;
c = in.get();
while (isdigit(c) || c==',') {
if (c != ',') {
order /= 10;
v += order * (c - '0');
}
c = in.get();
}
}
}
template void print_with_commas(ostream& os, fp_type v) {
char comma = use_facet >(cout.getloc()).thousands_sep();
if (v < 0) {
os << "-";
v = -v;
}
fp_type this_error = v * pow(10,-sig_figs);
long long integer_part = (long long)v;
int exp = 0;
long long power10_exp = 1;
while (power10_exp * 10 < integer_part) {
power10_exp *= 10;
exp++;
}
// skip leading zeroes
while (exp > 0 && (((integer_part / power10_exp) % 10) == 0)) {
power10_exp /= 10;
--exp;
}
// power_exp < integer_part < power_exp * 10
int limit = sig_figs;
while (exp > 0) {
os << (char)(((integer_part / power10_exp) % 10) + '0');
power10_exp /= 10;
if (exp % 3 == 0)
os << comma;
--exp;
--limit;
}
os << (char)((integer_part % 10)+'0');
fp_type dv(v);
if ((dv - integer_part) != 0 && limit > 0) {
// now we use for past the decimal place
os << ".";
unsigned short digit;
dv -= integer_part;
exp = -1;
while (this_error < dv && --limit > 0) {
dv *= 10;
this_error *= 10;
digit = (unsigned short)dv;
os << digit;
if (exp-- % 3 == 0)
os << comma;
dv -= digit;
}
}
}
template class btc_complex : public complex {
public:
btc_complex() : complex() {}
btc_complex(fp_type x) : complex(x) {}
btc_complex(fp_type a, fp_type b) : complex(a,b) {}
};
ostream& operator << (ostream& os, const btc_complex z) {
print_with_commas(os, z.real());
if (z.imag() != 0) {
os << "+";
print_with_commas(os, z.imag());
os << "I";
}
return os;
}
ostream& operator << (ostream& os, const btc_complex z) {
print_with_commas(os, z.real());
if (z.imag() != 0) {
os << "+";
print_with_commas(os, z.imag());
os << "I";
}
return os;
}
ostream& operator << (ostream& os, const btc_complex z) {
print_with_commas(os, z.real());
if (z.imag() != 0) {
os << "+";
print_with_commas(os, z.imag());
os << "I";
}
return os;
}
template istream& operator >> (istream& in, btc_complex& z) {
fp_type real, imag;
char c = in.get();
read_with_commas(in, real, c);
if (c =='I' || c=='i') {
z = btc_complex(0,real);
} else if (c == '+') {
read_with_commas(in, imag, c);
if (c != 'I') {
in.setstate(ios::failbit);
}
z = btc_complex(real,imag);
} else {
z = real;
in.putback(c);
}
return in;
}
struct test_case {
double val;
string lit;
};
int main(int argc, char **argv) {
{
try {
cout.imbue(std::locale("en_US"));
} catch ( ... ) {
}
test_case tests[] = { { 43112279.75467,"43,112,279.754,67"} , {0.0101020204,"0.010,102,020,4"}, {0.00000001,"0.000,000,01"} };
BOOST_FOREACH(test_case c, tests) {
ostringstream oss;
complex oz = c.val;
btc_complex z = c.val;
try {
oss.imbue(std::locale("en_US"));
} catch ( ... ) {
cout << c.val << " = " << z << endl;
oss << z;
if (oss.str() == c.lit) {
cout << "test successful." << endl;
} else {
cout << "test failed: expected " << c.lit << ", but got " << oss.str() << endl;
}
oss.str( "" );
}
BOOST_FOREACH(test_case c, tests) {
istringstream iss;
btc_complex z;
iss.str(c.lit);
iss >> z;
if (z == c.val) {
cout << "test successful." << endl;
} else {
cout << "test failed: expected " << c.val << ", but got " << z << endl;
}
}
}
return 0;
}
#include
#include
#include
#include
#include
#include
#include
#include
using namespace std;
# reads a number with thousand separators in it and one character that the value is put into v
# the last character read is left in c. The first character read in is c after that
# characters are read in from in.
template
int sign = 1;
if (c == '-') {
sign = -1;
c = in.get();
}
v = 0.0;
while (c != '.') {
if (c != ',') {
if (isdigit(c)) {
v *= 10;
v += (c - '0');
} else {
return;
}
}
c = in.get();
}
if (c == '.') {
fp_type order = 1;
c = in.get();
while (isdigit(c) || c==',') {
if (c != ',') {
order /= 10;
v += order * (c - '0');
}
c = in.get();
}
}
}
template
char comma = use_facet
if (v < 0) {
os << "-";
v = -v;
}
fp_type this_error = v * pow(10,-sig_figs);
long long integer_part = (long long)v;
int exp = 0;
long long power10_exp = 1;
while (power10_exp * 10 < integer_part) {
power10_exp *= 10;
exp++;
}
// skip leading zeroes
while (exp > 0 && (((integer_part / power10_exp) % 10) == 0)) {
power10_exp /= 10;
--exp;
}
// power_exp < integer_part < power_exp * 10
int limit = sig_figs;
while (exp > 0) {
os << (char)(((integer_part / power10_exp) % 10) + '0');
power10_exp /= 10;
if (exp % 3 == 0)
os << comma;
--exp;
--limit;
}
os << (char)((integer_part % 10)+'0');
fp_type dv(v);
if ((dv - integer_part) != 0 && limit > 0) {
// now we use for past the decimal place
os << ".";
unsigned short digit;
dv -= integer_part;
exp = -1;
while (this_error < dv && --limit > 0) {
dv *= 10;
this_error *= 10;
digit = (unsigned short)dv;
os << digit;
if (exp-- % 3 == 0)
os << comma;
dv -= digit;
}
}
}
template
public:
btc_complex() : complex
btc_complex(fp_type x) : complex
btc_complex(fp_type a, fp_type b) : complex
};
ostream& operator << (ostream& os, const btc_complex
print_with_commas
if (z.imag() != 0) {
os << "+";
print_with_commas
os << "I";
}
return os;
}
ostream& operator << (ostream& os, const btc_complex
print_with_commas
if (z.imag() != 0) {
os << "+";
print_with_commas
os << "I";
}
return os;
}
ostream& operator << (ostream& os, const btc_complex
print_with_commas
if (z.imag() != 0) {
os << "+";
print_with_commas
os << "I";
}
return os;
}
template
fp_type real, imag;
char c = in.get();
read_with_commas(in, real, c);
if (c =='I' || c=='i') {
z = btc_complex
} else if (c == '+') {
read_with_commas(in, imag, c);
if (c != 'I') {
in.setstate(ios::failbit);
}
z = btc_complex
} else {
z = real;
in.putback(c);
}
return in;
}
struct test_case {
double val;
string lit;
};
int main(int argc, char **argv) {
{
try {
cout.imbue(std::locale("en_US"));
} catch ( ... ) {
}
test_case tests[] = { { 43112279.75467,"43,112,279.754,67"} , {0.0101020204,"0.010,102,020,4"}, {0.00000001,"0.000,000,01"} };
BOOST_FOREACH(test_case c, tests) {
ostringstream oss;
complex
btc_complex
try {
oss.imbue(std::locale("en_US"));
} catch ( ... ) {
cout << c.val << " = " << z << endl;
oss << z;
if (oss.str() == c.lit) {
cout << "test successful." << endl;
} else {
cout << "test failed: expected " << c.lit << ", but got " << oss.str() << endl;
}
oss.str( "" );
}
BOOST_FOREACH(test_case c, tests) {
istringstream iss;
btc_complex
iss.str(c.lit);
iss >> z;
if (z == c.val) {
cout << "test successful." << endl;
} else {
cout << "test failed: expected " << c.val << ", but got " << z << endl;
}
}
}
return 0;
}
The last test fails with expected 1e-08 but got 0.000,000,01. 1e-08 clearly is the same as 0.000,000,01. I knew I was pushing my luck with a simple equality comparison for doubles. I forced US in the test case, so that the values can be tested.
Two common solutions are suffixes (m-, u-, n-) and spaces ( 0.00001 -> 0.000 01 ).
Even in cultures that use arabic numerals, the radix designator is not universally standardized. Plenty of people would have written my example as 0,000 01, and it gets worse if you also have a bunch of digits to the left.
Even in cultures that use arabic numerals, the radix designator is not universally standardized. Plenty of people would have written my example as 0,000 01, and it gets worse if you also have a bunch of digits to the left.
It is time people start using thousand separators (,) after the decimal place.
Is this easy to read? 1.00143781 or 1.001,437,81?
I believe that for most people the number 0.00001 BTC written as 0.000,01 BTC is a lot more readable.
Is this easy to read? 1.00143781 or 1.001,437,81?
I believe that for most people the number 0.00001 BTC written as 0.000,01 BTC is a lot more readable.
This could create more confusion, as different countries use different decimal separators, i.e. 1.00749781 <==> 1,00749781.
I think mBTC or satoshis would be a better unit of measure.
I like it
0.00001 BTC is better written as 1000 satoshis.
Sweet Jesus no. That looks wrong on so many levels. If you want to express amounts in mBTC or Satoshis and then use thousand separators where they're supposed to be, on the LEFT SIDE OF THE DOT, then people would understand it.
Jump to: