Any decimal number can be exactly represented this way.
Unless you are using javascript which treats decimals as floats  |
|
|
|
Great PR. Looks like the BBC is warming to bitcoin and shining a nice positive light upon it  |
|
|
|
Use a decimal type of which you explicitly set the precision to whatever required.
Don't confuse floats with decimals, they are completely different, a float is by definition an approximation, a decimal stores an exact value.
Don't ever listen to anyone suggesting floating point for financial calculations, they don't know what they're doing, no matter how much precautions and care you take floats are and remain approximations that are not suited for monetary amounts.
If you know the difference and know what you're doing there's really no need to use integers as storage type and handling type. Using an integer to store a decimal value in a high level language would show that you don't know exactly what you're doing.
The reason MtGox will return integers in their API responses is because there is no way to discriminate between decimal and float types in JSON, they are represented the same way. Therefore, if your parsing lib parses these as floats instead of proper decimals you're boned. But if it parses them as integers you have an opportunity to post-process these as proper decimals before actually using them.
Understood davout. Most languages these days can handle the different number types, decimal or float won't be an issue. Certainly in my specific cases using MySQL and PHP, these numbers are handled very well and very precisely. The issue arises with Javascript which is widely used these days. http://stackoverflow.com/questions/588004/is-javascripts-floating-point-math-brokenJavascript treats floats and decimals as the same type. When performing number manipulations for visual display then some issues might arise. The tricky aspect is... how do i use an Integer number format and have javascript run calculations whilst returning numbers in correct format? Can any javascript developers out there share their thoughts? |
|
|
|
I've worked in my real jobs extensively in retail and investment banking on a range of trading and reporting systems. Not a single one I have come across represents monetary value in integer format. (hence this discussion thread) Rounding within all banking systems (in my experience at least) occurs programatically in functions.
That's interesting - certainly all the banking software that I've seen (am talking *bank end* not UI) is still written in COBOL (developed in the 70's and patched in the 90's for the Y2K bug) where you use PIC variables which let you describe the numeric as a number of digits and number of decimal places. Am pretty certain that *under the covers* these are actually represented as integers (just not seen that way by the programmer even) as they don't suffer from the "binary floating point problems". My experience has mostly been with back end systems so raw data in SQL databases and mainframes. Data inputs for their front end systems will only accept 2 decimal places as valid data. Anything else input from either a data feed or directly would be rejected as a bad data input. I don't believe that it would matter whether you represent values in integer or in floating point as long as you have programmed your controls correctly. For calculations and rounding, there should can be a few issues. Eg: Using Integers: - Ensure that all calculations do not accept any decimal value and rounding is performed at integer level
- Ensure you have strict controls in your UI layer to process raw figures into the correct decimal representations
- * the tricky aspect here is knowing whether a figure read is a currency figure or a btc figure
Using float/decimals: - Ensure that all calculations are subject to the correct decimal rounding (eg if BTC, then always round every calculation to 8dp.
- Ensure that every language used represents decimals correctly
|
|
|
|
|
Apple products. Or are they already available?
|
|
|
|
Once again i'll submit to whatever the poll tells me to. ie: If 75% say yes it means i'll allocate 75% of my avail resources to bitcoin. So you're letting total strangers decide what you're going to do with your savings? Unbelievable. ... in fact, thats not any different to depositing your money in your local bank these days. |
|
|
|
One should always calculate and store in integer base units when dealing with Bitcoin amounts. Pool operators and other sites that have previously stored values in floats have been shamed out of existence.
There is consensus that from all the replies so far that integers are the way forward, and I would totally agree, from a IT/developer's perspective this makes sense. I've worked in my real jobs extensively in retail and investment banking on a range of trading and reporting systems. Not a single one I have come across represents monetary value in integer format. (hence this discussion thread) Rounding within all banking systems (in my experience at least) occurs programatically in functions. however work will be required in the display logic of a site / program.
I don't see how this is a problem. You're already using extra logic to escape user input, format timestamps, generate urlencoded links, etc. Agreed, it isn't an issue however the logic would either have to be built into the calculation layer (ie your programming) or the visual presentation layer if you were to store values in decimal or integer format respectively. I'd like to know what everybody's preference is and why. Second to this, looking at the mtgox api, values are stored in not one, not two, but THREE formats: - Display value
- Float/Double/Decimal value
- Integer value
|
|
|
|
|
I'd like to open up a discussion about the different way you as developers have approached the problems of decimal handling when working on bitcoin projects.
Because bitcoin is divisible down to 8 decimal places, calculations on float / decimal numbers can be a pain in a number of languages (as numbers may never appear exact even if displayed correctly).
When working on the MtGox api, they have marked the decimal value representations as legacy. It appears they are moving away from anything decimal related and using integers (which is multiplied by 1e-8 when displayed for bitcoin). This makes calculations simpler in whatever language you are programming in, however work will be required in the display logic of a site / program.
What are your programming practises for handling the many decimals that bitcoin provides?
I'd like to hear from you if you run a bitcoin site or even a wallet program, btcjam / satoshidice / electrum etc... ?
|
|
|
|
|
Thanks Dooglas, claim in.
|
|
|
|
What are the thoughts on how things are going to be distributed? eg. Where to send the bitcoins?
I'm thinking I'll put up a very cut-down clone of the WBX software which will allow you to log in using the same OpenID credentials as you used at WBX, and will ask you for a bitcoin address for the funds to be sent to, and will allow you to make additional comments about your account, and upload supporting documentation. What's not clear is how long to wait before distributing the funds. I guess the first set of funds can be distributed immediately upon the 1 year anniversary, which will be calculated with the assumption that everyone will put in a claim. But I doubt everyone will, so there will be some funds left over - and I don't know what to do with those. Some people will presumably find out about the repayments late. I want to still be able to refund them up to some point in time and not have to tell them "sorry - you're too late". But I don't want to be holding funds indefinitely hoping for claimants to come forward. So I guess some kind of cut-off date is needed. Ideas? - Set up the site, give everybody x months to place a claim. - Make payments - Job done * Make it very clear that those who do not submit a claim will lose out. This is as similar to a real liquidation process where the information of debtors is not readily available. The choice is yours dooglus, but something tells me you'd rather be rid of this mess sooner rather than later. Additionally, I'd like to add that given so much time is passed. I'm after quick action to be taken and a shorter 1 month claim window to be used. |
|
|
|
I was having a look into currency API's today for a project I have in the works. OpenExchangeRates offers a free currency API for general use. While reading about it, I came across a section in the FAQ referring to Bitcoin!! I thought this might be of interest to a few of you here: https://openexchangerates.org/faq#bitcoin |
|
|
|
Thanks for your words of support sonba. Hence, I still vote to pay out the money pro rata after 1 year has passed of Andre telling us about his exchange being closed (see 1st post).
This seems reasonable. I can't keep holding the BTC indefinitely, and one year seems like long enough for Andre to have responded to my attempts to contact him. After a year I can only think he has abandoned the exchange and its users. Here's the email announcing WBX's shutdown. That seems like a good time to count as the official end. I'll note the last traded price on the USD MtGox market at the first anniversary of that time, and use the mid-market AUD/USD exchange rate on http://www.xe.com/ucc/ to convert to AUD to get the rate at which I'll calculate the percentage of balances to return. Note that the timestamp quoted below is in the PDT timezone, so I'll be using the price at 3:39pm PDT, Monday 11th March 2013. On Sun, Mar 11, 2012 at 3:39 PM, Andre Jensen < gorkalitus@gmail.com> wrote: Dear Clients, Effective immediately World Bitcoin Exchange (WBX) will be shutting down trading / deposits and returning all client funds. [...] I'm also in support of this action and share similar views to XTremeEd. With the days and months going by, the chances of hearing back from Andre are going to reduce. This'll also depend on how good his record keeping is, which I do not have any faith in given how he handled the situation. The one thing I am most grateful for is your call dooglus to hold on to the BTC when Andre asked for it back. Good call . Given I get a semi-decent amount back eventually, I'll be sending a few btc your way. |
|
|
|
|
Nope, transactions that have happened since will sync up again eventually.
|
|
|
|
Download: http:// ge.tt/3CppLwT/v/0
I do appreciate the work you do to promote Electrum. However, I am very concerned by binaries distributed by third parties, because this is a potential vector for malware. I guess this binary uses the --portable flag on startup, and this (hopefully) is the only difference. why don't you ask slush to create an official "portable" executable file with this option? +1, is there an option for a portable build on the official site? |
|
|
|
|
Nice... but wheres the english?
|
|
|
|
|
Impressed at the very positive slant they had on this topic. That woman sure was liberal and had no shame in expressing her views. Amen to that. A refreshing piece.
|
|
|
|
are you implying an uptrend?!  well for like 2 months we have been in a up trend... now the market must either continue up, or start a down trend. resistance and support are both strong, its anyone's guess.... I guess down, maybe alot, at least a little +1 for a downtrend |
|
|
|
I raised this suggestion a while back and still believe it to be a good idea however didn't get much consensus: Interesting point, I see where you're coming from... that its a shame that so many bitcoins will never be realized as they're just forgotten about.
Just a thought... if an expiry system was introduced, similar to land leases, 99 years would be a good benchmark for expiry... and the miners could once again mine the coin. Not sure if this would be technically possible though.
That way the reintroduction will be very slow and not affect the economy a huge amount, however it would ensure 100% circulation of all 21million bitcoins each 100 years.
If in the future you have old coins that are > 90 years old, I'm sure it wouldn't be too much trouble to send them to a new address or re-create that new offline wallet.
Why not 80? 40? If you could make changes like that it would break trust, can't so won't so we're fine. Historically I'm using an age old concept as a suggestion of how the policy could work: http://en.wikipedia.org/wiki/99-year_leaseUnder the traditional American common law doctrine, the 99-year term was not literal, but merely an arbitrary time span beyond the life expectancy of any possible lessee or lessor. Who's trust would it break given that the owner of the coins would have died meaning the coins will be out of circulation anyway? Redistribution of expired coins can be done once again through mining such as how coins are currently distributed. Whole thread here: https://bitcointalk.org/index.php?topic=112525.msg1218706#msg1218706 |
|
|
|
|
Threadbump... anyone there?
|
|
|
|
|
Show Posts
