tag:blogger.com,1999:blog-8930529650384824164.post7718994120495633854..comments2023-05-07T08:36:04.125-06:00Comments on Merchant Monarchy: Market History LiesMoxNixhttp://www.blogger.com/profile/12407914481361718041noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-8930529650384824164.post-42393505542231518602014-09-15T12:57:35.726-06:002014-09-15T12:57:35.726-06:00Just bug some CSM member or directly CCP about it....Just bug some CSM member or directly CCP about it. We already have corp transaction history and lately the corp blueprint list in the API, so maybe they can also add a "raw" history to the Crest/XML API, since it requires no changes to the client/game.<br /><br />We also need to keep in mind, that the ingame market values are designed for your average "Joe", so defining what are "good" low/high values is subjective. I personally would use something like this:<br /><br />1) remove the lowest and highest 1% of transactions this day.<br />2) calculate the lowest 5% percentile and highest 5% percentile<br /><br />I guess for some items 10% or 15% percentile might be more informative to the average "Joe", so you see its not this easy to work this out.Unknownhttps://www.blogger.com/profile/11246377640188435621noreply@blogger.comtag:blogger.com,1999:blog-8930529650384824164.post-45441345969393813452014-09-15T10:06:41.021-06:002014-09-15T10:06:41.021-06:00BTW, they could easily fix most of the problems wi...BTW, they could easily fix most of the problems with extreme outliers if they'd just change the order filling logic so when you enter a buy order way higher than the lowest sell order it fills your order from existing sell orders at the sell order price first. And just the opposite for sell orders lower than existing buy orders, fill them from existing buy orders at the buy order price.<br /><br />Just like how real life markets work.MoxNixhttps://www.blogger.com/profile/12407914481361718041noreply@blogger.comtag:blogger.com,1999:blog-8930529650384824164.post-78875905843661055162014-09-15T10:01:25.634-06:002014-09-15T10:01:25.634-06:00Yup, understood. I took it to mean high / low anyh...Yup, understood. I took it to mean high / low anyhow.<br /><br />I can't argue with anything you or lucas had to say. After all you seem to think it works pretty much the same way I think it does. I just don't like the way it works. I'd real prefer hard data with real numbers, not numbers massaged, manipulated and edited to show what some coder or economist thinks the numbers should be.<br /><br />Sure I can understand dropping extreme outliers (0.01 ISK sell orders and 10x typos kind of thing) but IMO they go way too far with that, it winds up distorting the data and misrepresenting what's really happening.<br /><br />Granted that's not a big deal with high volume items like PLEX but like I said in the OP it is a problem with slow moving items that don't sell every day.<br /><br />And yeah I'd love to see it further broken down with separate numbers for buy orders and sell orders but I don't see that happening.MoxNixhttps://www.blogger.com/profile/12407914481361718041noreply@blogger.comtag:blogger.com,1999:blog-8930529650384824164.post-81922603863383544782014-09-15T05:08:03.931-06:002014-09-15T05:08:03.931-06:00I meant "low" and "high" rathe...I meant "low" and "high" rather than "min", "max". This is the semantic distinction btw, since min/max would actually mean something different than more loose terms "low", "high".Unknownhttps://www.blogger.com/profile/11246377640188435621noreply@blogger.comtag:blogger.com,1999:blog-8930529650384824164.post-79283348050710666782014-09-15T05:05:38.993-06:002014-09-15T05:05:38.993-06:00As far as i understand this, the low/high are not ...As far as i understand this, the low/high are not simple min/max of all sales, but in itself represent a "moving min/max" value calculated over time.<br /><br />So to use the plex example, i would assume that getting plex at 755m was only in a short window of time and the rest of it is more close to the "low" value this day. The other problem is that it combines buy and sell orders and we have no separated history or i would expect the values would make more sense.<br /><br />I don't think the history "lies", since it never actually states that it will display the "lowest" singular sale this day. In fact the history chart has not a single value that displays singular sale/buy events. The idea for those charts is to display a "smoothed" or averaged record of what happened this day. <br />So unless you account for 30-50% of the volume this day at 755m, it is totally fine to "record" the history of the price at min 782m and max 793m.<br /><br />I always interpret those values as "the most likely price" i can get. So i would expect that i could buy at 782m with little effort and at the average 791m at none.<br /><br />Don't get me wrong, i would also like more numbers and certainly see reasons to also include something like a daily 5% min/max of that day, but personally i'm not interested in the "lowest" or "highest" sales number, without also having the volume listed.<br /><br />So just interpret those numbers as "smoothed" values, rather than representing absolute or singular events.Unknownhttps://www.blogger.com/profile/11246377640188435621noreply@blogger.comtag:blogger.com,1999:blog-8930529650384824164.post-58278373646619566782014-09-15T01:27:02.567-06:002014-09-15T01:27:02.567-06:00Sometimes the market data gets lost. When there&#...Sometimes the market data gets lost. When there's zero entries on a given day, the prices get carried over from the previous day (the average I think goes across all 3, but it's early so gimme a break) so that the average price gets carried. Look at items that are nearly never sold and you'll see the same effect.<br /><br />As for pricing differences, there's some hidden criteria which drops certain sales off of the pricing to stop people being able to manipulate prices too easily. Strong outliers almost certainly get dropped, but there's other circumstances things will not qualify too. CCP keeps what the criteria is close to the chest for obvious reasons.Lucas Kellhttps://www.blogger.com/profile/03969897349629783605noreply@blogger.com