[BETA]Bitfinex.com first Bitcoin P2P lending platform for leverage trading

[unclescrooge]

on a side-note: whatever happened to "don't use floating point for financial apps"? ;-)

No floating point are used here, nowhere

[molecular]

on a side-note: whatever happened to "don't use floating point for financial apps"? ;-)

No floating point are used here, nowhere

I see numbers like 349.99999 and 1490.00008 regularly. I figured those were floating point artifacts.

[unclescrooge]

on a side-note: whatever happened to "don't use floating point for financial apps"? ;-)

No floating point are used here, nowhere

I see numbers like 349.99999 and 1490.00008 regularly. I figured those were floating point artifacts.

The numbers stored and manipulated by the app are bigdecimal (an accurate type of decimal unlike float). Interests rates are stored and calculated as a daily rate internally, hence why you don't always get a round number when switching to 365-days rate.

[superbit]

It would be nice if you could pre-set a loan offer that your daily interest will go into by percentage. ie

50% in 60 days at 400%
25% in 90 days at 300%
25% kept as cash 

[myself]

@Sukrim after your another ppl complains about taken loans on and off in a non consistent way i did get to the obvious conclusion that you the lenders need more tools and more info on the same way banks have a credit score so i put together a draft that will be submitted to R soon(tm) and i named this Bitfinex Credit Consistency Score also there have to be take few steps to prepare for this score said steps are already planet for a better matching on lending service BFX provide

[Ichthyo]

on a side-note: whatever happened to "don't use floating point for financial apps"? ;-)

As a software developer, I feel inclined to add the following.

You often hear "floatinig point is evil". Mostly this is an urban legend.
Floating point numbers can be dangerous only when used naively.

More specifically, there is a standard-type of floating point number in many programming languages, which is often called "float". The key point is that this number type uses only the so called single precision (3 bytes mantissa, 1 byte exponent). This is enough to represent roughly 4 places without error. And this is indeed not sufficient for financial math.

But there are several alternatives available on pretty much every platform. Most prominently, just use double precision math, which is also supported by the hardware. Many programming languages provide also a software implemented floating point number (often called "big decimal"), which uses variable precision. The downside of the latter is that it can be 100 times slower than a hardware based math.

But none of these alternatives solves the rounding problem (which is fundamental; some numbers simply can't be represented precisely in finite). The only solution is to deal knowingly with the problem and especially to round only for the presentation and for the end results, never for intermediary results.

[Killdozer]

But none of these alternatives solves the rounding problem (which is fundamental; some numbers simply can't be represented precisely in finite). The only solution is to deal knowingly with the problem and especially to round only for the presentation and for the end results, never for intermediary results.

That's not he problem at all. The problem is that numbers less than 0 which can be represented exactly in decimal system, not always can be represented EXACTLY in binary. Sure, you can have double and quadriple precision and perhaps make some sort of checks which will treat numbers like 0.29999999999999 as 0.3, but that's more like workarounds. The only right way to do financial software is exact decimal types.

[molecular]

First: I'm sorry to hijack this thread and veer offtopic so hard.

But none of these alternatives solves the rounding problem (which is fundamental; some numbers simply can't be represented precisely in finite). The only solution is to deal knowingly with the problem and especially to round only for the presentation and for the end results, never for intermediary results.

That's not he problem at all. The problem is that numbers less than 0 which can be represented exactly in decimal system, not always can be represented EXACTLY in binary. Sure, you can have double and quadriple precision and perhaps make some sort of checks which will treat numbers like 0.29999999999999 as 0.3, but that's more like workarounds. The only right way to do financial software is exact decimal types.

This is owed to the fact that the financial world uses decimal. If these guys weren't bankers but mathematicians, the only right way to write software for them would be to use some certain kind of symbolic expressions.

Side-note: Back when I joined Bitcoin there was some dude on irc (forgot his name, he might still be around) constantly trying to convince people we should use a kind of base-16 number system (not hexadecimal, but similar, I forgot the name, some other bloke tried to convince people in britain in the 19th century to use it and failed) for bitcoin. That would've clearly prohibited any sort of success for bitcoin in my mind.

You often hear "floatinig point is evil". Mostly this is an urban legend.
Floating point numbers can be dangerous only when used naively.

More specifically, there is a standard-type of floating point number in many programming languages, which is often called "float". The key point is that this number type uses only the so called single precision (3 bytes mantissa, 1 byte exponent). This is enough to represent roughly 4 places without error. And this is indeed not sufficient for financial math.

I agree that the problem is not using floating point but storing/calculating in binary and displaying in decimal. The fact that "some numbers" cannot be represented with finite number of digits is not very relevant. While this - apart from numbers like sqrt(2) or sqrt(-1) - includes some commons numbers like 1/3, you're unlikely to encounter these numbers in this setting (because they can't be entered in decimal by a user). Of course it might pop up when you're trying to make 3 slices from one pizza or something (1 pizza is a financial unit now, I hear), but usually you just give everyone 0.33 pizzas and pocket the remaining 0.01 yourself in such a case.

I also agree this is pretty much a non-issue (just using double precision and rounding only at display time should work in most cases)

I'm not sure the concerns about speed of floating point decimals are an issue either. In a database-heavy app you usually have other performance bottlenecks that are much more severe.

Maybe it's interesting to note that IBM (used to) put decimal floating point arithmetic instructions into some of their CPUs: http://www.ibm.com/developerworks/wikis/display/hpccentral/How+to+Leverage+Decimal+Floating-Point+unit+on+POWER6+for+Linux

I'll try to honor Ichthyos advice.

But none of these alternatives solves the rounding problem (which is fundamental; some numbers simply can't be represented precisely in finite). The only solution is to deal knowingly with the problem and especially to round only for the presentation and for the end results, never for intermediary results.

[Ichthyo]

But none of these alternatives solves the rounding problem which is fundamental; some numbers simply can't be represented precisely in finite).

That's not he problem at all. The problem is that numbers less than 0 which can be represented exactly in decimal system, not always can be represented EXACTLY in binary. Sure, you can have double and quadriple precision and perhaps make some sort of checks which will treat numbers like 0.29999999999999 as 0.3, but that's more like workarounds. The only right way to do financial software is exact decimal types.

Come on. The only way to do financial software properly is to know and understand what you are doing.

There is no silver bullet. Never. Don't believe people which tell you that "exact decimal types" is the wonder solution, or "rapid prototyping", or "trading bots" or "straight through processing" solve every problem or whatever. Only ever do what you understand throroughly.

[Ichthyo]

First: I'm sorry to hijack this thread and veer offtopic so hard.

IMHO this is quite on topic here. Its project development and Bitcoinica was known to have precision problems.

I'm not sure the concerns about speed of floating point decimals are an issue either. In a database-heavy app you usually have other performance bottlenecks that are much more severe.

My understanding too. An application like what we're discussing here will probably first run into overload at the DB connection and then at the external network connections, given the CPUs are suitably dimensioned. In the larger, more heavyweight trading applications at some point the situation becomes different. There one tries not rely on a DB, but keep working data in memory, using clusters of replicated nodes with high reliability. Only the result stream is then fed to persistent storage. In such a setup, it could be a bad idea to use Big Decimal for calulations.

[molecular]

got this error trying to redeem a mtgox USD code



I redeemed it back to myself on gox for now.

[unclescrooge]

Hello Molecular,

The problem is solved now, you can deposit Mtgox code on Bitfinex!

Best regards,
Raphael

[molecular]

Hello Molecular,

The problem is solved now, you can deposit Mtgox code on Bitfinex!

Best regards,
Raphael

confirmed, thanks.

another feature request: you display "lendable balance", that's very good, but it includes amounts tied up in offers that have not been taken yet. How about another entry "lendable balance minus amounts tied up in offers" (you'd have to think of a better name, of course). That way I would know the maximum amount I can use for a new offer. Maybe you could even prefill that into the "amount" field instead of "1" or "0", but I'm not sure about that one.

[Ichthyo]

Variable Interest Rate, current: 464414.96%

[myself]

Variable Interest Rate, current: 464414.96%

down to 237382.3112%

[Ichthyo]

Variable Interest Rate, current: 464414.96%

down to 237382.3112%

What shall I we do?

With this rates its just a question of minutes to run into a margin call!

At the moment I am doing nothing; my reasoning is that this must be a bug

[Ichthyo]

there is a loan offer
100      100000010.0%       700.0 

maybe someone has taken that accidentally. But I thought, the averaging would protect the VIR rates against such glitches?

[myself]

What shall I we do?

With this rates its just a question of minutes to run into a margin call!

At the moment I am doing nothing; my reasoning is that this must be a bug

close your VIR loans

[myself]

there is a loan offer
100      100000010.0%       700.0  

maybe someone has taken that accidentally. But I thought, the averaging would protect the VIR rates against such glitches?

if this type of loans are taken the VIR will go up
    

      60    3610.0%    168.73    1
      60    4000.0%    1000.0    1
      60    14000.0%    40.9    1
      60    350010.0%    160.0    1
      60    750010.0%    100.0    1
      60    1000000.0%    0.18    

[Ichthyo]

What shall I we do?

With this rates its just a question of minutes to run into a margin call!

At the moment I am doing nothing; my reasoning is that this must be a bug

close your VIR loans

I have a highly profitable position right now. And the market is moving sideways or up.
If I close my VIR loans, I need to close 80% of my positoin.

If it is a bug, shouldn't you just halt the trading engine?