Quote
pedant
is it wrong that I laughed my ass off at this post?
Topic: TradeHill API was coded by amateurs (Read 2892 times)
is it wrong that I laughed my ass off at this post?
Sending decimal numbers as numbers invites clients to interpret them as floats and thereby introduce rounding errors. It's not a bad idea to transfer fixed point decimal numbers as strings.
Correct. This is actually a feature borne out of wisdom dealing with lots of different languages and runtimes which may not support floating point math accurately or as expected when doing conversions to other types.
gigi is the idiot.
EDIT: and just to clarify, using a string type let's you, the API user, determine how to re-cast and interpret the value rather than dealing with side effects of some implementation which tries to "do the right thing" by default.
This is all correct and makes sense. I would also like to add that in order to serialize a decimal.Decimal() (which i can almost guarantee they are using).
You have to cast it to a native type beforehand. Your choices are: str(), int() or float().
The choice is obvious
...
BTW, I'm gigi, a programmer with 30 years experience in coding financial systems, great business development skills, and was CEO of a major investment bank for 10 years...
BTW, I'm gigi, a programmer with 30 years experience in coding financial systems, great business development skills, and was CEO of a major investment bank for 10 years...
You are clearly a poor programmer. Get over yourself.
Sending decimal numbers as numbers invites clients to interpret them as floats and thereby introduce rounding errors. It's not a bad idea to transfer fixed point decimal numbers as strings.
Correct. This is actually a feature borne out of wisdom dealing with lots of different languages and runtimes which may not support floating point math accurately or as expected when doing conversions to other types.
gigi is the idiot.
EDIT: and just to clarify, using a string type let's you, the API user, determine how to re-cast and interpret the value rather than dealing with side effects of some implementation which tries to "do the right thing" by default.
Indeed, this is not that out of the ordinary.
I heard tonight that they use python for their backend. (+1 over the php using mtgox)
So the are most likely using the Decimal data type from the standard lib. This is not strange.
What I think should happen is crap like this should be removed as soon as it is realized it is crap. You are tarnishing the name of a business.
Or the OP should have contacted TradeHill with their little 'discovery' before pulling this.
How many scrolled through the forums, saw "TradHill API was coded by amateurs" without taking the time to find out the truth?
That sentiment is now floating around in their subconscious.
I heard tonight that they use python for their backend. (+1 over the php using mtgox)
So the are most likely using the Decimal data type from the standard lib. This is not strange.
What I think should happen is crap like this should be removed as soon as it is realized it is crap. You are tarnishing the name of a business.
Or the OP should have contacted TradeHill with their little 'discovery' before pulling this.
How many scrolled through the forums, saw "TradHill API was coded by amateurs" without taking the time to find out the truth?
That sentiment is now floating around in their subconscious.
Alright great, I disagree with OP.
At least we all can agree OP is a moron though.
At least we all can agree OP is a moron though.
The troll threads tonight have been neverending. This is one of the worst, along with that "proof" thread where the OP didn't understand that a large sell order would not be matched by a single large buy order.
The posturing wannabe programmer here is almost as bad.
Why must they post photos? We don't demand proof and photos of EVERY bitcoin-related exchange.
Alright great, I disagree with OP.
At least we all can agree OP is a moron though.
At least we all can agree OP is a moron though.
OP is a moron.
You'd generally export those values as strings for enhanced readibility when combined and thrown together in, say, a table. Key word here is EXPORT.
You act as if there is no way to convert that json element back to a float.... silly.
You'd generally export those values as strings for enhanced readibility when combined and thrown together in, say, a table. Key word here is EXPORT.
You act as if there is no way to convert that json element back to a float.... silly.
Such an ironic mistake is pretty amateurish, no?
Although you gotta admit that the guy is pretty darn good at getting worked up, pointing fingers, and name-calling.
Quote
A senior level programmer would not make this trivial mistake. My firm
ftfy
pedant
Actually I'm glad they send numbers as strings, as that's the way it should be done. It's up to the requesting script to determine how to handle the data.
Ok, now that everybody agrees that I'm a moron regarding the JSON, any comments of my pictures requests?
BTW, I'm gigi, a programmer with 30 years experience in coding financial systems, great business development skills, and was CEO of a major investment bank for 10 years. Trust me, because I say so on the Internets. (check the "TradeHill - Who we are" thread if you don't get it)
BTW, I'm gigi, a programmer with 30 years experience in coding financial systems, great business development skills, and was CEO of a major investment bank for 10 years. Trust me, because I say so on the Internets. (check the "TradeHill - Who we are" thread if you don't get it)
I vote in the "It doesn't matter" category. I program for a living so yeah that's my qualifications for this statement.
I don't think it matters either way. Any properly written parser would use explicit conversion and not rely on conversion to the default types provided by JSON specs.
TradeHill is doing the correct thing here. This is totally standard.
http://blog.programmableweb.com/2010/10/19/the-twitter-id-shuffle-text-vs-numbers/
http://blog.programmableweb.com/2010/10/19/the-twitter-id-shuffle-text-vs-numbers/
OP is a moron.
You'd generally export those values as strings for enhanced readibility when combined and thrown together in, say, a table. Key word here is EXPORT.
You act as if there is no way to convert that json element back to a float.... silly.
You'd generally export those values as strings for enhanced readibility when combined and thrown together in, say, a table. Key word here is EXPORT.
You act as if there is no way to convert that json element back to a float.... silly.
Sending decimal numbers as numbers invites clients to interpret them as floats and thereby introduce rounding errors. It's not a bad idea to transfer a fixed point decimal numbers as strings.
What about the other numbers which are integers?I deal with a lot of Forex sites, they list the quotes as numbers - http://rates.fxcm.com/RatesXML
The problem you are describing is real, and that is why the Decimal data type was invented (fixed point decimal, like you said).
Sending decimal numbers as numbers invites clients to interpret them as floats and thereby introduce rounding errors. It's not a bad idea to transfer fixed point decimal numbers as strings.
Look at the way the JSON response from their API is formatted.
https://api.tradehill.com/API/USD/Trades
https://api.tradehill.com/API/USD/Orderbook
How it is (notice the " around values):
How it should be (notice the lack of " around values):
A senior level programmer would not make this trivial mistake. You do not send numbers out as strings. My firm wouldn't even hire for junior level the people who designed such a thing. The other exchanges at least format these responses correctly. And they still got hacked due to other vulnerabilities. How can I trust the security of a site dealing with money, when they can't get basic stuff like JSON right?
I noticed this since I started logging their prices (for historical purposes), but I feel compelled to point it out now since there is lot of talk about how "professional" they are and due to the attack people started searching for Mt Gox alternatives.
What I would like to see is for TradeHill to post pictures of their faces, their offices, their infrastructure, each one of them including the secure timestamp from a Financial Times copy.
Cryptographic secure timestamp:
http://upload.wikimedia.org/wikipedia/en/6/6c/Guardtime_timestamping_newspaper_publication.png
https://api.tradehill.com/API/USD/Trades
https://api.tradehill.com/API/USD/Orderbook
How it is (notice the " around values):
Code:
{"date": "1308278023", "tid": "4667", "price": "17.20010000", "amount": "10.00000000"}How it should be (notice the lack of " around values):
Code:
{"date": 1308278023, "tid": 4667, "price": 17.20010000, "amount": 10.00000000}A senior level programmer would not make this trivial mistake. You do not send numbers out as strings. My firm wouldn't even hire for junior level the people who designed such a thing. The other exchanges at least format these responses correctly. And they still got hacked due to other vulnerabilities. How can I trust the security of a site dealing with money, when they can't get basic stuff like JSON right?
I noticed this since I started logging their prices (for historical purposes), but I feel compelled to point it out now since there is lot of talk about how "professional" they are and due to the attack people started searching for Mt Gox alternatives.
What I would like to see is for TradeHill to post pictures of their faces, their offices, their infrastructure, each one of them including the secure timestamp from a Financial Times copy.
Cryptographic secure timestamp:
http://upload.wikimedia.org/wikipedia/en/6/6c/Guardtime_timestamping_newspaper_publication.png
Jump to: