Separators after the decimal place.

[sdp]

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.

[Blazr]

The ideal solution would be to write it in a different unit such as milliBTC.

So 1.00143781 BTC  becomes 1001.143781 mBTC, much easier to read.

[Remember remember the 5th of November]

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.

No it's not, why on earth did you even think of this?

[wopwop]

sdp has spoken

it is time

[threeip]

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.

No it's not, why on earth did you even think of this?

[Caesium]

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.

[Buffer Overflow]

0.00001 BTC is better written as 1000 satoshis.

[dave111223]

I like it

[someguy123]

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.

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.

Well, mBTC already causes enough confusion. I really hate when sites try to tell me I'm going to get 0,1 mBTC or 12,1 uBTC 

[kjj]

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.

[sdp]

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.

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 <iostream>
#include <algorithm>
#include <string.h>
#include <locale>
#include <math.h>
#include <complex>
#include <ctype.h>
#include <boost/foreach.hpp>
#include <sstream>
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<class fp_type> 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<class fp_type,int sig_figs> void print_with_commas(ostream& os, fp_type v) {
		char comma = use_facet<numpunct<char> >(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 fp_type> class btc_complex : public complex<fp_type> {
public:
	btc_complex() : complex<fp_type>() {}
	btc_complex(fp_type x) : complex<fp_type>(x) {}
	btc_complex(fp_type a, fp_type b) : complex<fp_type>(a,b) {}
};

ostream& operator << (ostream& os, const btc_complex<double> z) {
	print_with_commas<double,15>(os, z.real());
	if (z.imag() != 0) {
		os << "+";
		print_with_commas<double,15>(os, z.imag());
		os << "I";
	}
	return os;
}
ostream& operator << (ostream& os, const btc_complex<long double> z) {
	print_with_commas<long double,19>(os, z.real());
	if (z.imag() != 0) {
		os << "+";
		print_with_commas<double,19>(os, z.imag());
		os << "I";
	}
	return os;
}
ostream& operator << (ostream& os, const btc_complex<float> z) {
	print_with_commas<long double,6>(os, z.real());
	if (z.imag() != 0) {
		os << "+";
		print_with_commas<double,6>(os, z.imag());
		os << "I";
	}
	return os;
}

template<class fp_type> istream& operator >> (istream& in, btc_complex<fp_type>& z) {
	fp_type real, imag;
	char c = in.get();
	read_with_commas(in, real, c);
	if (c =='I' || c=='i') {
		z = btc_complex<fp_type>(0,real);
	} else if (c == '+') {
		read_with_commas(in, imag, c);
		if (c != 'I') {
			in.setstate(ios::failbit);
		}
		z = btc_complex<fp_type>(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<double> oz = c.val;
		btc_complex<double> 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<double> 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;
}

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.

[Dayne]

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!

[sdp]

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!

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.

[jackjack]

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'

[Abdussamad]

You can just use satoshis and you won't have to worry about decimal points.

[DeathAndTaxes]

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.

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

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://bitcointalk.org/index.php?topic=227532.0

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!".

[Sukrim]

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.

[greyhawk]

> separators after the decimal place.

Don't tell me you named yourself after that idea.... 

[sdp]

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.

[Sukrim]

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:

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.