| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Ortos
Abyssus Incendia
THORN Alliance
   |
Posted - 2008.05.10 18:35:00 -
[1]
Someone was wondering how a stack of 1 trillion trit would look like. I tried to figure out, but it's impossible to stack more then 2,147,493,647. And by that time, if you stacked em all on top of eachother, theyre likely to fall down.
|
Ray McCormack
hirr
|
Posted - 2008.05.10 19:09:00 -
[2]
The shocking thing is that this is the most insightful post on this forum for quite some time.
|
Ortos
Abyssus Incendia
THORN Alliance
|
Posted - 2008.05.10 19:14:00 -
[3]
I know, I made an effort didnt I?
|
Jawbreaker x
|
Posted - 2008.05.10 19:56:00 -
[4]
2,147,493,647. = 2^31 ,it looks 32bit limit to me  ,
|
Kazuo Ishiguro
House of Marbles
Zzz
|
Posted - 2008.05.10 23:31:00 -
[5]
Edited by: Kazuo Ishiguro on 10/05/2008 23:33:02
Actually, the number ought to be 2147483647, or 2^31 - 1. This is also the maximum possible number of jumps between systems (a 32-bit signed integer).
I wonder why they needed to use a signed integer? It's not as though we ever have negative numbers of items in a stack. Also, I wonder what they use for wallet balances? Mine's been larger than that for some time without causing any trouble.
My research services
Spreadsheets: Top speed calculation - Halo Implant stats |
Ortos
Abyssus Incendia
THORN Alliance
|
Posted - 2008.05.11 15:03:00 -
[6]
If people wish to figure out feel free to fill up my wallet to see how high the cap is. I promise another thread where the quality actually *gasp* exceeds this one. =)
|
Selene D'Celeste
Caldari
The D'Celeste Trading Company
|
Posted - 2008.05.11 16:38:00 -
[7]
When I ran into this a long time ago, my theory was that they used a signed integer either out of a) laziness or b) they have some sort of contorted system where the same numbers that represent stacks are used to represent changes to those stacks via transactions. Thus you can sell (have a -) of as many as you can buy/have at once, which is the stack limit. I can't even imagine why the hell they would do this, but this is CCP, I don't even pretend thought went into these kinds of things anymore.
|
Ortos
Abyssus Incendia
THORN Alliance
|
Posted - 2008.05.11 17:18:00 -
[8]
It' most likely done to reduce lag.
1 unit in a 32 bit string = 32 bit
1 unit in a 64 bit string = 64 bit
And it's pretty rare for people to have more then 2 billions of an item anyhow. And when people have that many items, having two stacks instead of one isent really that big off a deal. Lets not pretend it happens too often :P
|
Selene D'Celeste
Caldari
The D'Celeste Trading Company
|
Posted - 2008.05.12 01:23:00 -
[9]
 Originally by: Ortos
It' most likely done to reduce lag.
1 unit in a 32 bit string = 32 bit
1 unit in a 64 bit string = 64 bit
There was no question about a 64-bit value. The interesting thing pointed out is that the integer is signed, and the question is, why would you need negative values of an item amount?
|
Kylar Renpurs
Dusk Blade
|
Posted - 2008.05.12 01:41:00 -
[10]
Thinking about it, the only logical thing I can come up with is it's a convoluted way to change the number of items in a stack due to consumption, perhaps in a slightly more secure way (having no idea about that side of the house behind the scenes).
I.e. I manufacture something requiring 2,000 units of trit and pye. Instead of just taking 2000 units off those stacks, I "Add a stack of -2000 trit/pye to your stack of trit/pye".
It's convoluted and maybe even useless sure, but it's all I've got.
In fact, it makes a lot of sense. "Every action has an equal and opposite reaction". It basically ties any client request to modify/create an item stack to a particular action (buying, selling, splitting, manufacturing, loading into a module etc.). If 'stack' operations were not used, there'd be a function which allows a client to "change" the quantity on any given stack without much reason, which would be a security issue IMO.
Improve Market Competition! |
Kwint Sommer
Lothian Quay Industries
|
Posted - 2008.05.12 02:28:00 -
[11]
Edited by: Kwint Sommer on 12/05/2008 02:28:27
Originally by: Kylar Renpurs
Thinking about it, the only logical thing I can come up with is it's a convoluted way to change the number of items in a stack due to consumption, perhaps in a slightly more secure way (having no idea about that side of the house behind the scenes).
I.e. I manufacture something requiring 2,000 units of trit and pye. Instead of just taking 2000 units off those stacks, I "Add a stack of -2000 trit/pye to your stack of trit/pye".
It's convoluted and maybe even useless sure, but it's all I've got.
In fact, it makes a lot of sense. "Every action has an equal and opposite reaction". It basically ties any client request to modify/create an item stack to a particular action (buying, selling, splitting, manufacturing, loading into a module etc.). If 'stack' operations were not used, there'd be a function which allows a client to "change" the quantity on any given stack without much reason, which would be a security issue IMO.
I fail to see what signed integers accomplish that preventing the client from issuing "add to stack" commands wouldn't. Allow the client only to merge and subtract from stacks and you have the same result without the need for signed integers.
EDIT: Because the forum ate my post. 
Purchasing and Shipping Moon Minerals |
Raskor
Crossflow Enterprises
|
Posted - 2008.05.12 03:10:00 -
[12]
Originally by: Kazuo Ishiguro
I wonder what they use for wallet balances?
Given that they maintain 2 digits of precision on sale amounts, taxes, balances, etc,... it is likely a type float or double, more likely the latter.
|
Shinhan
Phoenix Knights
THORN Alliance
|
Posted - 2008.05.12 06:53:00 -
[13]
Originally by: Raskor
Originally by: Kazuo Ishiguro
I wonder what they use for wallet balances?
Given that they maintain 2 digits of precision on sale amounts, taxes, balances, etc,... it is likely a type float or double, more likely the latter.
Actually, they maintain 4 digits of precision but show only 2 to players. And they could still use int64 with last 4 digits reserved for decimal points.
But I do agree that signed integers are used WAAAAY too often.
--
Selling apples, 1 signature each.
ѼѼѼѼѼѼѼ |
Shadarle
|
Posted - 2008.05.12 17:41:00 -
[14]
Originally by: Kazuo Ishiguro
Edited by: Kazuo Ishiguro on 10/05/2008 23:33:02
Actually, the number ought to be 2147483647, or 2^31 - 1. This is also the maximum possible number of jumps between systems (a 32-bit signed integer).
I wonder why they needed to use a signed integer? It's not as though we ever have negative numbers of items in a stack. Also, I wonder what they use for wallet balances? Mine's been larger than that for some time without causing any trouble.
Indeed, the wallet cap is well beyond this number. It's in the trillions as far as I can tell, if not beyond that.
|
Kypud
Zeus Enterprises
|
Posted - 2008.05.12 19:10:00 -
[15]
Probably wasn't a specific reason to use signed instead of unisgned, the original developer was in a rush to meet a deadline and just used signed. Then it became too much of a hassle to change it.
As for the wallet, never use float or double for money. The precision of these types is not precise. Probably decimal(x,4), where x is suitably high.
why, oh why, did I get sucked into this thread?
|
Emily Spankratchet
Minmatar
Pragmatics
|
Posted - 2008.05.13 15:08:00 -
[16]
Originally by: Kypud
Probably wasn't a specific reason to use signed instead of unisgned, the original developer was in a rush to meet a deadline and just used signed. Then it became too much of a hassle to change it.
I'd put money on this. Never try to find a complex reason behind something that can be explained by programmer laziness and/or stupidity.
|
Ortos
Abyssus Incendia
THORN Alliance
|
Posted - 2008.05.13 20:14:00 -
[17]
Originally by: Kypud
why, oh why, did I get sucked into this thread?
I dunno but I got nothing to do with that!
|
Jarek Naumen
Ataraxia.
|
Posted - 2008.05.13 20:42:00 -
[18]
Originally by: Kylar Renpurs
Thinking about it, the only logical thing I can come up with is it's a convoluted way to change the number of items in a stack due to consumption, perhaps in a slightly more secure way (having no idea about that side of the house behind the scenes).
I.e. I manufacture something requiring 2,000 units of trit and pye. Instead of just taking 2000 units off those stacks, I "Add a stack of -2000 trit/pye to your stack of trit/pye".
It's convoluted and maybe even useless sure, but it's all I've got.
In fact, it makes a lot of sense. "Every action has an equal and opposite reaction". It basically ties any client request to modify/create an item stack to a particular action (buying, selling, splitting, manufacturing, loading into a module etc.). If 'stack' operations were not used, there'd be a function which allows a client to "change" the quantity on any given stack without much reason, which would be a security issue IMO.
QFT... but a bit more clarified:
You need to store negative values to simplify code logic and operations. You encapsulate some of the operations' logic within the variable value (+ or -) and don't have to worry about all kinds of external logic all the time, and you eliminate some conditionals.
In english: you don't have to make a difference between addition and substraction, it's always just addition.
|
Brisco Smiley
Peppermint Bay Trading Company
|
Posted - 2008.05.13 21:15:00 -
[19]
Originally by: Raskor
Originally by: Kazuo Ishiguro
I wonder what they use for wallet balances?
Given that they maintain 2 digits of precision on sale amounts, taxes, balances, etc,... it is likely a type float or double, more likely the latter.
IEEE-754, double precision. I've seen it make rounding errors.
|
Ki Tarra
Caldari
Ki Tech Industries
|
Posted - 2008.05.14 19:25:00 -
[20]
Eve is built on MSSQL.
A simple explination for these limitations can be found by looking at the data types available.
Unsigned integers are not supported by MSSQL. The overhead created by hacking code out to force support for unsigned integers would probably be worse than simply using a larger sized integer.
32 bit signed integer is plenty for most item stacks, and the few cases were someone might want a larger stack is unlikely to justify the extra overhead created by doubling the size of a field to 64 bit, especially on a field that occurs so frequently.
As for wallet balances, using the money data types would be the most obvious choice, and is consistant with the 4 decimal place accuracy for market transactions which is only rounded for display purposes. Given the amounts needed they would have gone with an 8 byte version. If you want another challange: try to get a wallet balance over 922,337,203,685,477.5807 
|
Selene D'Celeste
Caldari
The D'Celeste Trading Company
|
Posted - 2008.05.15 03:08:00 -
[21]
Edited by: Selene D''Celeste on 15/05/2008 03:09:11
Originally by: Raskor
Originally by: Kazuo Ishiguro
I wonder what they use for wallet balances?
Given that they maintain 2 digits of precision on sale amounts, taxes, balances, etc,... it is likely a type float or double, more likely the latter.
This is incorrect. As was mentioned, it's 4 points of precision, but that is only with ISK values.. But the limit being mentioned is on an INTEGER amount of items in a stack. Different things.
And Ki Tarra for the win on doing the research there =)
|
Roemy Schneider
BINFORD
|
Posted - 2008.05.15 08:13:00 -
[22]
Originally by: Ki Tarra
If you want another challange: try to get a wallet balance over 922,337,203,685,477.5807
hold on...
-
putting the gist back into logistics |
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |