Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Ethereum Smart Contracts

gjermundbjaanes.com

Post reply on HN
Print view View original

101–110 of 162 posts

Re: Understanding Ethereum Smart Contracts

#101

Post by Kranar »

bhaak wrote: post #98
Kranar wrote: post #89

Earlier quoted context omitted.

>That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable application in the "classic" financial sector. I feel like this is constantly repeated but is simply untrue and work…

But you are working in HF trading. Speed is paramount there. The common programmer has no clue about the numerical instabilities that floating point numbers are causing. Your examples are exactly what I would expect from a capable engineer that is pondering the different pros and cons when you have to optimize your code. Calling BigDecimals entirely unneeded tells me you are in a luxury position where you can draw fr…

Not every single aspect of HFT is insanely speed critical and even in non-critical areas we still don't use fixed decimal point arithmetic on principle. For example we do a lot of profit/loss reporting and analytics which are not speed critical, we write user interfaces and web apps in Javascript that work with money, so on so forth.

I will agree BigDecimal is fine to use if speed really doesn't matter, it's at least correct even if it's a nuclear option of sorts. What I really want to discourage is using fixed integer to represent some smallest unit of money, like using an int where 100 = 1 dollar, 1010 = 10 dollars and 10 cents. That is fundamentally problematic and objectively worse than using a floating point value.

But sure, if you genuinely don't want to think at all about the issue, use your language's BigDecimal. If you decide you want the much improved performance, then use a floating point value, either the IEEE decimal floating point standard or use binary floating point to represent some reasonably small unit fraction of a dollar, like 1.0 = 10^-6 dollars.

Re: Understanding Ethereum Smart Contracts

#102

Post by shock-value »

Kranar wrote: post #89
Slartie wrote: post #39

Earlier quoted context omitted.

> There are no floating point numbers. Since you're probably working with "money", this can make things tricky. That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable appli…

>That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable application in the "classic" financial sector. I feel like this is constantly repeated but is simply untrue and work…

What you are saying may be true of finance. But it's not true of accounting, in which exact figures are paramount.

Re: Understanding Ethereum Smart Contracts

#103

Post by Kranar »

Slartie wrote: post #95
Kranar wrote: post #89

Earlier quoted context omitted.

>That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable application in the "classic" financial sector. I feel like this is constantly repeated but is simply untrue and work…

Self-quote: > any imaginable application in the "classic" financial sector Kranar: > working in the financial sector (high frequency trading) Okay, you got me there - you have pointed me to that single application from the financial sector where it is not totally acceptable to "waste" a few thousands of processor cycles to compute some money-related stuff. Granted, in HFT applications, these cycles may allow you to g…

>I work in the retail industry (think cash registers, retail sale accounting, that kind of stuff) and pretty much any legislation on this planet would obliterate us if we'd tell them that the result of the computations of our systems may be some cents up or down from the real result - the one someone would get who just scribbled the numbers on a sheet of paper and added them up manually.

It is especially in cases like this that you absolutely should not use fixed decimal point systems to represent money. It is exactly in these circumstances that your fixed decimal point system will eventually encounter a situation where it fails catastrophically.

Intel provides an IEEE decimal floating point system specifically for the purpose of adhering to legal requirements, they say so right at the top of their website:

https://software.intel.com/en-us/articles/intel-decimal-floa...

If fixed point math would have solved this issue, they'd have provided a solution involving that, but fixed point math is simply the absolute worst solution to this problem, even worse than naively using a 64-bit binary floating point number.

BigDecimal is also a viable solution, but it's entirely unnecessary and the cost really is enormous especially if you need to handle a large number of transactions. But sure, if you say performance genuinely isn't an issue go with BigDecimal.

Re: Understanding Ethereum Smart Contracts

#104

Post by cratering »

alvarosevilla95 wrote: post #18
dsr_ wrote: post #12

I am particularly amused that in the first example, a simple counter, no mention is made of the initialization routine being callable at any point... at which time the counter is reset to zero.

If I'm not mistaken in Solidity constructors can only be called once on a contract

Yes that is correct http://solidity.readthedocs.io/en/develop/contracts.html#cre...

Re: Understanding Ethereum Smart Contracts

#105

Post by filmor »

Slartie wrote: post #95
Kranar wrote: post #89

Earlier quoted context omitted.

>That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable application in the "classic" financial sector. I feel like this is constantly repeated but is simply untrue and work…

Self-quote: > any imaginable application in the "classic" financial sector Kranar: > working in the financial sector (high frequency trading) Okay, you got me there - you have pointed me to that single application from the financial sector where it is not totally acceptable to "waste" a few thousands of processor cycles to compute some money-related stuff. Granted, in HFT applications, these cycles may allow you to g…

> pretty much any legislation on this planet would obliterate us if we'd tell them that the result of the computations of our systems may be some cents up or down from the real result

But you are not some cents up or down, even if you are calculating with billions, you still have 7 significant digits, that's a lot of head room for calculations.

Are there any financially sensible calculations where large numbers (order of magnitude billions) are multiplied with each other?

Re: Understanding Ethereum Smart Contracts

#106

Post by barbersturgeon »

Kranar wrote: post #101
bhaak wrote: post #98

Earlier quoted context omitted.

But you are working in HF trading. Speed is paramount there. The common programmer has no clue about the numerical instabilities that floating point numbers are causing. Your examples are exactly what I would expect from a capable engineer that is pondering the different pros and cons when you have to optimize your code. Calling BigDecimals entirely unneeded tells me you are in a luxury position where you can draw fr…

Not every single aspect of HFT is insanely speed critical and even in non-critical areas we still don't use fixed decimal point arithmetic on principle. For example we do a lot of profit/loss reporting and analytics which are not speed critical, we write user interfaces and web apps in Javascript that work with money, so on so forth. I will agree BigDecimal is fine to use if speed really doesn't matter, it's at least…

Honest question - why is that something to avoid? What does the floating point representation buy you that say an int64 doesn't, with the same choice of units ie. 1 = 10^-6 dollars?

Re: Understanding Ethereum Smart Contracts

#107

Post by Slartie »

Kranar wrote: post #103
Slartie wrote: post #95

Earlier quoted context omitted.

Self-quote: > any imaginable application in the "classic" financial sector Kranar: > working in the financial sector (high frequency trading) Okay, you got me there - you have pointed me to that single application from the financial sector where it is not totally acceptable to "waste" a few thousands of processor cycles to compute some money-related stuff. Granted, in HFT applications, these cycles may allow you to g…

>I work in the retail industry (think cash registers, retail sale accounting, that kind of stuff) and pretty much any legislation on this planet would obliterate us if we'd tell them that the result of the computations of our systems may be some cents up or down from the real result - the one someone would get who just scribbled the numbers on a sheet of paper and added them up manually. It is especially in cases lik…

> BigDecimal is also a viable solution, but it's entirely unnecessary and the cost really is enormous especially if you need to handle a large number of transactions. But sure, if you say performance genuinely isn't an issue go with BigDecimal.

That is exactly what we currently do, and speed of computations is definitely not an issue at all. If we have performance related problems (and we do sometimes), they have never in 10 years originated from numerical computation just taking too long, but always from other inefficiencies, quite often of architectural nature that uselessly burn a thousand times more cycles than the numeric part of the job.

BigDecimal provides exactly what we need: a no-brainer, easy-to-use, easy-to-understand and always correct vehicle for the calculation of monetary sums. It lets our developers focus on implementing the business logic, and also on making less of the described high-level failures that get us into actual performance troubles, instead of consuming a lot of mental share just to “get the computation right“ in all circumstances.

Re: Understanding Ethereum Smart Contracts

#108

Post by jcoffland »

jackpeterfletch wrote: post #96
Brotkrumen wrote: post #73

Earlier quoted context omitted.

The only thing seckimjohn showed is that contracts, paper or "smart", are only as good as they're written. Since contracts such as _red gave, "we are friends, this is our company, we share the EBT equally", exist right now, it's a perfectly realistic use case for a smart contract. Hell, I'd even do that for a small project. Smart contracts being fixed and errors being exploitable is a valid criticism but it's not the…

No its fundamental. In the trust fund example, you cant stop the recipient trading their key or wallet early, as you have no way to verify the human holding it. Unless you keep that access with some legal guardian. In which case your security still sits in the legal system, as it would if you just used a trust fund. So whats the point? Again in the company example, it only works if you both observe that the coins mea…

What's to stop someone from trading a normal trust fund away? The recipient can simply take out a loan with the trust as collateral.

Re: Understanding Ethereum Smart Contracts

#109

Post by latencyloser »

Kranar wrote: post #89
Slartie wrote: post #39

Earlier quoted context omitted.

> There are no floating point numbers. Since you're probably working with "money", this can make things tricky. That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable appli…

>That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable application in the "classic" financial sector. I feel like this is constantly repeated but is simply untrue and work…

I worked on the exchange side(CME Group) and we used BigDecimal (and an in-house version that worked in a very similar way) quite often... Worked just fine for us as far as I know.

That being said, I agree with your sentiment that there are faster/more efficient ways to accomplish this. For something like smart contracts, I'd think they should be able to abstract this line of reasoning into an API that's consumable for those of us that aren't as familiar. Or is at least worth having the option of.

Re: Understanding Ethereum Smart Contracts

#110

Post by alexasmyths »

ringaroundthetx wrote: post #65
SeckinJohn wrote: post #47

Earlier quoted context omitted.

1- 50% of what? Revenue into the company or dividens/salary etc out of the company? if it's the latter, then, how do we make sure that you don't spend $500.000 for trash bins for the office? Do we have to make sure every decision goes through the network? (i.e. who is the authority to decide what is reasonable and what is blatant fraud if things go sour AND is it even possible to make sure that nothing possibly can g…

regarding number 2, the child would not have a way of selling that Ethereum before 2035.

" the child would not have a way of selling that Ethereum before 2035"

In 'no legal land' it would be easy enough to sell a bunch of 'locked until 2035' etherium - wrapped in another ether contract like a future or something. Much the same way lottery winners who get an annuity instead of a lump sum can then sell that annuity for a lump sum.

Post reply on HN