I've been using Auctioneer for some time now and I just love it. The best addon imho. Can't imagine trading in AH without it!

There is one problem when ppl set their prices. Some ppl type silver prices accidentally to gold price field. So if they intended to put an item for 25s starting bid and 50s buyout, they make 50g buyout instead. This can happen with start bid also. Those prices screws up the average counting for starting bid and buyout, rendering them useless. The good thing is that there is median value to help determining the real price but it would be nice to have averages as well.

I'd suggest that the addon would exlude those wrong prices each time it does the scan. Don't know exactly how to do it but I have this idea. Check the price against median price and if it's more than a treshold value (say 50 times) higher, then exclude the price.

Would somebody agree with me? Also, is this possible to implement with the addon?

Artix, lv 36 hunter at Sylvanas

Posted by: Guest on Oct 14 2005, 02:53 PM

There is one problem when ppl set their prices. Some ppl type silver prices accidentally to gold price field. So if they intended to put an item for 25s starting bid and 50s buyout, they make 50g buyout instead. This can happen with start bid also. Those prices screws up the average counting for starting bid and buyout, rendering them useless. The good thing is that there is median value to help determining the real price but it would be nice to have averages as well.

I'd suggest that the addon would exlude those wrong prices each time it does the scan. Don't know exactly how to do it but I have this idea. Check the price against median price and if it's more than a treshold value (say 50 times) higher, then exclude the price.

Would somebody agree with me? Also, is this possible to implement with the addon?

Artix, lv 36 hunter at Sylvanas

I agree this would be a great addition. The threshold multiplier over median price should be user setable for personal taste but 50 times median BO (or maybe average BO... not sure) sounds reasonable. Personally I would choose a much lower multiplier say 10 to 20 times median or avereage to also weed out deliberatly exhorbitant prices as well as the accidental.

I suspect you would need a 'minimum seen' before employing this setting to allow initial data to be built up. Of course I may be completly wrong and it might be very hard to make it work right but at first glance it seems simple enough

--
Thanks for a great mod
Thedoc, 34 Priest [EU-Bloodhoof]

Well, maybe throw out, or flag items who have prices outside 1 or 2 standard deviations? This might help get rid of the outliers (88g would DEFIANTELY be an outlier v 88s).

Posted by: Guest on Nov 10 2005, 07:31 PM
This is, by no means, accidental. The people do it on purpose, in hopes of catching someone unawares (like I was caught, losing 88g in the process on 20xMageweave Cloth). I would agree that something should be done to prune those results, though.

Sorry for the first post being like this.

But, you can use the Q test to identify statistically irrelevant data. What this will do is take the following data set:

45 48 41 44 45 42 45 44 47 47 61

And analyze the 61 to see if it is within the range to be included in the set for analysis, or if it is too far out of range, kick the erroneous data point to avoid skewing the analysis.

The problem is, it is only supposed to be used once per data set. However, in WoW economic statistics, I don't think we need an a=0.05 confidence level, so weakening the test a bit by removing wildly different data would make the entire analysis stronger.

However, there must be a limit to it. I'd allow it to kick no more than 2 data points from the set. That should provide maximum accuracy.

Here's a brief, but concise explaination with the formula.

http://science.widener.edu/svb/stats/qtest.html

Hope this helps.

Posted by: Ojciec on Dec 7 2005, 06:21 PM

45 48 41 44 45 42 45 44 47 47 61

And analyze the 61 to see if it is within the range to be included in the set for analysis, or if it is too far out of range, kick the erroneous data point to avoid skewing the analysis.

Ok, but lets say we eliminate 61...

Then the next time we scan, we get a 62, which we eliminate.

Then on subsequent scans, we get 63, 62, 61, 65, 63, 64, 69... All eliminated.

Can you see where I am going with this?

Economics change for a myriad of different reasons, perhaps the drop rate of a particular item was reduced, or increased. Perhaps all the engineers on your server picked up tailoring/chanting all the sudden. Perhaps Blizzard opened up realm transfers on your server.

Auctioneer is there to tell you how it changes, not to tell it that it can't change.

We record and display the statistics, you interpret them. Your expertise in navigating this minefield determines your success or failure.

If we could easily solve this problem without throwing away potentially good data, it would have been done by now. As it is, I believe Araband's "windowed" median solution tracks the ebb and flow of the economy quite well, provided you have enough data to start with and don't just blindly buy stuff on it's say so.

Please people - do some damn research before you buy. Auctioneer certainly isn't meant to be a bot. Such use would clearly be against the TOS and we would be hesitant to add any feature which negated the need for human skill.

If you get ripped of for buying something stupid without knowing why then it's your own fool fault as far as I am concerned.

Posted by: Guest on Oct 14 2005, 02:53 PM
I've been using Auctioneer for some time now and I just love it. The best addon imho. Can't imagine trading in AH without it!

There is one problem when ppl set their prices. Some ppl type silver prices accidentally to gold price field. So if they intended to put an item for 25s starting bid and 50s buyout, they make 50g buyout instead. This can happen with start bid also. Those prices screws up the average counting for starting bid and buyout, rendering them useless. The good thing is that there is median value to help determining the real price but it would be nice to have averages as well.

I'd suggest that the addon would exlude those wrong prices each time it does the scan. Don't know exactly how to do it but I have this idea. Check the price against median price and if it's more than a treshold value (say 50 times) higher, then exclude the price.

Would somebody agree with me? Also, is this possible to implement with the addon?

Artix, lv 36 hunter at Sylvanas

.. One way to do it, if it is possible to calculate the mean price, would be to ignore any prices more than 2 standard deviations away from the mean. Not fantastic but should help a lot.

Posted by: Norganna on Dec 12 2005, 02:13 PM
If we could easily solve this problem without throwing away potentially good data, it would have been done by now. As it is, I believe Araband's "windowed" median solution tracks the ebb and flow of the economy quite well, provided you have enough data to start with and don't just blindly buy stuff on it's say so.

Here is a question. On my server, we have 4-5 people that constantly post auctions where they have a small bid amount but the BO is ALWAYS 99 gold no matter what the item.

I know that median will take care of that but I was wondering if there could be an option to either exclude certain players from the SCAN or for certain amounts.

Thanks

Posted By: Imported (Norganna)Economics change for a myriad of different reasons, perhaps the drop rate of a particular item was reduced, or increased. Perhaps all the engineers on your server picked up tailoring/chanting all the sudden. Perhaps Blizzard opened up realm transfers on your server. If we could easily solve this problem without throwing away potentially good data, it would have been done by now.

Right, just a "brief" comment to add to this. What seems to be a feasible way to filter out erroneous bids without tainting the data set, would be the following. Do note that this is the result of a brainstorm and not that of a thorough research. Still, it may help.

First of all, for performance reasons using this method, it may be advised to keep the data sets sorted. So a data set of 5 3 6 4 6 34 should be kept as 3 4 5 6 6 34. The chronology is important, but will be considered later on.

Do not remove any values from the data set. So a set of 3 4 5 6 6 34 would keep the 34, even though it's clearly out of the estimated bounds. However, keep track of the estimated maximum price at all times. Seeing these values, the script may assert an estimated maximum price of 10 gold (arbitrary values are used for this example).

When calculating the averages from the data set, the script will only use the values up to the estimated maximum price. Since all values are kept, as prices increase/decrease the estimated maximum price can be adjusted and the output of Auctioneer will remain fairly accurate.

Now, as a sidetrack, there's a disadvantage to the sorting part of this method. The disadvantage would become clear when a drastic and lasting change occurs in a very large data set. The recalculation of the estimated maximum price could be a bit too slow according to some people's taste (and depending on the algorithm used to derive the value from the data set). I have too little experience in WoW addon performance issues to be certain which is worse: processing large data sets (factor 2) or run-time sorting instead of sorting while accumulating. Should a factor 2 on the data set size be acceptable, then it is always possible to keep both the chronological set, as also the sorted set. This would open up the opportunity for the script to weigh the values according to their relative age.

Should the performance of the on-the-fly sorting be sufficient, the initial step of sorting the data set during accumulation may be omitted. It would then be required to sort the data set on-the-fly prior to processing output using an estimated maximum price.

edit: Removed some typo's.

Grollyvarst: A lot of people who want to do advanced things like this usually get the excel spreadsheet converter and then do their own calculations.

here is the main post, I think.

this might also be helpful.

this is completely different, but might also be helpful somehow.