Talk:GetSellValue

Categorize

Is there a category this falls under othan than {{wowapi}}? User:Lessthan1337/Sig 20:40, 13 June 2007 (UTC)

Uh... not that I know of, it's the only non-addon-specific user created API I've seen on the wiki. Hard to categorize a solitary page IMO :P User:Tekkub/Sig 00:38, 14 June 2007 (UTC)

Would it not make sense to place a link for it on the User Defined Functions page? I know it's somewhat special. But if an addon author is looking for a function to provide prices, he might find it there and can then consider if the idea fits his requirements. --Bam 14:10, 14 June 2007 (UTC)

Other Community API Proposals

Great idea, Tekkub.

I'm wondering if it might be feasible to promote a similar UI community standard for AH prices -- there's almost as many auctioning aids out there as vendor-price monitors. Any other addon that wants to make use of that data has to have custom support for each of them, which is likely to break each time those addons' authors release new versions.

I'd start a page for GetAuctionMarketValue, but I'm not sure yet that's the best name for it... User:Fizzwidget/Signature 20:01, 13 September 2007 (UTC)

I love the idea, and the devs that implemented this certainly seem open to adding an auction one. The real question is, what do we need? Auction is a tad more complex... you got bid or buyout... average, high sell, recommended.... what exactly should we be asking for? Should there be one API or many (GetAuctionPrice (returns bid and buyout) vs GetAuctionBuyoutPrice + GetAuctionBidPrice)... What values do you use in ReagentCost? User:Tekkub/Sig 07:47, 14 September 2007 (UTC)

Yeah, auction prices are a much fuzzier field than vendor prices and people might want more flexibility to match. Honestly, I'm not sure about what other authors might want from an auction price API -- I'm a little surprised that I haven't run across addons other than my own that want to make use of auction price data without trying to gather it themselves. (Then again, I've not looked very hard.)

As for ReagentCost... my aim with it has long been to present as simple a summary of market value as possible, giving the user a "ballpark" idea of how much they'd be likely to spend buying ingredients and of which recipes stand a better chance of turning a profit. It's kind of the opposite of what Auctioneer and its ilk do -- it makes sense for them to present all kinds of statistical data, means vs medians, historic comparisons, etc., as they're most concerned with whether the one item you're looking at now is a good buy (or sell) right now. But when you're adding up the possible costs of all the mats in a recipe (and possible sub-recipes), questions of whether this reagent or that might be deviating from a "normal" price (and by how much) turn into noise... add up all the uncertainties and you get a wide, shallow bell curve. When the user just wants to know whether she's better off farming or buying the ingredients for her new LW pattern, telling her "well, it could be anywhere from 12g to 83g" doesn't help that much. I do still present a "confidence" number (based on the number of auctions seen for each item, and averaged across all mats in the recipe) so that there's at least an indication of whether there's a reasonable amount of data supporting the price summary, though.

Oh, and tending towards instant gratification myself, I use buyout prices exclusively in ReagentCost. (Again, I figure most of the questions it's there to answer have a time component... if I'm going to have to wait out a 24 hour auction to get my mats, I may as well just send one of my lackeys out to farm 'em.)

Anyway, GetAuctionBuyoutPrice + GetAuctionBidPrice seems like a natural way to do an API... wouldn't care for the latter myself, but I suppose someone else might. Either way, they should return at least two values: the price (mean, median, whatever your best guess for "normal" is), and some indicator of how good the data supporting that guess is (times seen, or maybe just a 0.0-1.0 confidence scale).

--User:Fizzwidget/Signature 08:53, 16 September 2007 (UTC)

The other addon I know of that depends heavily on prices is GarbageFu (A port/rewrite of my old ItemizedDeductions). That also runs entirely off Buyouts, so I think we've got that question answered. I agree that a confidence number would be good... it should probably be a percent and the auction addon should figure it on it's own. Probably something along the lines of the percent of seen prices that fall within the stddev of the mean price. Or maybe the size of the stddev in relation to the mean... God I hate Statistics :)

The other thing to consider is the price source. GarbageFu tells the user where the price came from, in case of multiple sources. We might want to pass back the addon's name as a 3rd return in case they want to know where the price came from. Hrm... but then we might want to make the API allow for specific polling and then we're making stuff more complex than need be. Big tradeoff....

I say we ask people to implement price, accuracy = GetAuctionBuyoutPrice(itemid or itemlink) for now and see how it turns out. I've been meaning to rip apart GarbageFu and rewrite my old ItemDed without the Fubarness, maybe this would give me somethnig to test with. User:Tekkub/Sig 20:35, 17 September 2007 (UTC)

Ah ha! After a lil wikipedia research, it looks like we're after Coefficient of variation. It's simply (stddev/mean). Subtract that from 1 and we have an accuracy percent. For example, if the item has a mean price of 100g and a stddev of 8g, we'd have an accuracy of 92%. If we had a mean of 50s and a stddev of 20s, we'd have an accuracy of 60% User:Tekkub/Sig 20:57, 17 September 2007 (UTC)

Sounds great: price, accuracy = GetAuctionBuyoutPrice(itemid or itemlink) it is, then!

As for the accuracy number, though: what ReagentCost is doing is reporting on the sample size; i.e. "Has this item been seen at auction a lot, or do we only have a couple data points from which to guess at its normal price?" CV, on the other hand, is a measure of how dispersed the sample is. They're two different measures, though both valuable -- you could have a low CV (indicating a very focused distribution) on a sample that's still so small it may not be indicative of market value, or a high CV (indicating data that's all over the place) on a large sample.

But the goal here is to leave the heady statistics to the auction mods, so that clients of this proposed API can concentrate on doing useful stuff with auction prices instead of trying to figure out how accurate they are. I'd be content to just define accuracy as a number between 0.0 and 1.0 indicating how confident the auction mod is in price. They're free to estimate price by as simple or complex a method as they choose, so they may as well use whatever measures are appropriate to their method in quantifying the reliability of that estimate. --User:Fizzwidget/Signature 00:29, 22 September 2007 (UTC)

This idea of one function that we can all implement sounds good for vendor prices where there is only one answer, but AH data is fluid, what happens when two or three mods that implement the same function are present at the same time? Its not uncommon to find both WoWEcon and Auctioneer on the same machine, but we have vastly different prices. Mëñtå!Pøwër Ť © 04:36, 22 September 2007 (UTC)

That's why you hook the func if it's there? This is to provide a one-stop "get any price" solution... if the dev wants specific support for a specific addon, they write it in directly. User:Tekkub/Sig 08:04, 22 September 2007 (UTC)

Reverting

I'm re-reverting my changes back in. If it really was buggy I'd be more accepting, but the code works fine. Here is test code including copy-pasted version of the code I had on this page:

-- Pretend something already defined this API, to test fallback to the hook if our function doesn't know a price
function GetSellValue(item)
	ChatFrame1:AddMessage("GetSellValue("..tostring(item)..")")
end

-- Define our function, it doesn't know every price
local function YourItemPriceFunc(id)
	if id < 20 then 
		ChatFrame1:AddMessage("YourItemPriceFunc("..id..")")
		return 5
	end
end

--Copy-paste from the wiki
local origGetSellValue = GetSellValue
function GetSellValue(item)
    local id = type(item) == "number" and item or type(item) == "string" and tonumber(item:match("item:(%d+)"))

    if not id and type(item) == "string" then -- Convert item name to itemid, only works if the player has the item in his bags
        local _, link = GetItemInfo(item)
        id = link and tonumber(link:match("item:(%d+)")) 
    end

    return id and (YourItemPriceFunc(id) or origGetSellValue and origGetSellValue(id))
end

--And now make some test calls to see if it works
GetSellValue(10) -- Should get a value from YourItemPriceFunc
GetSellValue("item:123") -- Should call origGetSellValue(123) This tests both the fallback to hook, and that we're parsing links correctly
GetSellValue("item:12:123:456:789") -- Should get a value from YourItemPriceFunc
GetSellValue("enchant:666") -- Test a link that GetItemInfo wouldn't accept.  This one should return out without calling any of our functions

And the output:

YourItemPriceFunc(10)
origGetSellValue(123)
YourItemPriceFunc(12)

Please don't call the code buggy without testing it yourself. As for "unreadable"... did you not know about the logic trick, only if-else blocks? Saving to a local and then returning it is not necessary, and in fact returning the value directly from the function is better on performance, because we get a tail call. "Readability" is in the eye of the beholder... User:Tekkub/Sig 03:04, 15 November 2007 (UTC)

Fine, if you want to cry "discuss first" but not discuss it in the talk page, both versions are going up. Also, the "readable" version will bug out if a bad value is passed (not number or string) or if no itemid can be found when a string is passed and a hook is called (it's passing nil to the hook when it shouldn't be calling the hook at all) User:Tekkub/Sig 23:10, 15 November 2007 (UTC)

"'item' must take the same values GetItemInfo does". GetItemInfo() does NOT accept a nil, and do you notice the word "must" there? GetSellValue MUST not accept nil! Polarina 14:17, 16 November 2007 (UTC)

And your version, if it can't convert the string into an itemid, calls the hook and passes a nil. It should either be passing the original arg, or just not calling the hook at all because it was passed a bad arg. GII fails with an argcheck assert, my version simply silently returns out nil/false (but it could throw an error if I wanted). Your version creates a different invalid arg and continues calling the hook chain. User:Tekkub/Sig 21:34, 16 November 2007 (UTC)

Ops.. That certainly was not an intended behaviour. Thanks for letting me know. --Polarina 22:43, 16 November 2007 (UTC)

Your version will also fail with a weird error if the arg passed isn't a string or number. You need to either argcheck that they are correct at the start and throw an error or return out, or you need to not expect a string in your blanket "else" block. User:Tekkub/Sig 22:46, 16 November 2007 (UTC)

Yes, that was intended. As the explanation for the GetSellValue implementation said it must only accept the same arguments as GetItemInfo, who apperantly doesn't handle nils. --Polarina 22:56, 16 November 2007 (UTC)

Then why not perform a few simple asserts and throw an error like GII does, instead of a somewhat cryptic execution error about trying to call "match" on a table where it doesn't exist or something similar if the arg passed isn't the wrong type? User:Tekkub/Sig 23:04, 16 November 2007 (UTC)

Why not? We can just simply put a "commented out" code with the assert if that's preferred. --Polarina 23:08, 16 November 2007 (UTC)

I think, especially with the "readability" argument, that throwing specific errors would be better than failing with some error created during runtime when we know the arg type can't be handled. User:Tekkub/Sig 23:20, 16 November 2007 (UTC)

But errors are because of incorrect usage. Lua would be a lot slower if it did check arguments for sanity in all their C functions. It's like sanity checking all the arguments returned from Blizzard's functions! --Polarina 23:40, 16 November 2007 (UTC)

Also, examples are for illustrative purpose only and not for optimizations unless a article is about code optimizations.

      (02:32:00 PM) <Polarina>: JoshBorke: Who's version would you prefeer as the only example instead of including both?
      (02:32:15 PM) <batrick>: the one more instructive
      (02:33:45 PM) <batrick>: performance except inside an article discussing it, should not be the focus inside a wiki article
      (02:33:57 PM) <batrick>: it should be clarity and completeness about what you're talking about
      (02:34:08 PM) <batrick>: yours is both, but you might want to include more comments

Polarina 15:17, 16 November 2007 (UTC)

IMO one should not sacrifice optomizations anywhere. the code is readable if you understand the language's "tricks". Yes, everything can be broken down into big if-then-else blocks and be made to take up 4 pages with tons of white space, but some people find that kind of code ugly and not any more readable than somewhat more concise versions. Keep both versions, because yours has it's issues :P User:Tekkub/Sig 21:34, 16 November 2007 (UTC)

I dont get it

I copied all this code and It just returns nil for everything I put into it. I've put in itemID, Itemlinks, and names. How does this work? I'm looking at the code and I don't see any Blizzard API calls. But that can't be - how else would anyone know the price if you can't ask the Server? Obviously, I'm missing something. —The preceding unsigned comment was added by Peeka (talk · contr).

The point is that you CAN'T ask the server for that info, so we're trying to provide a consistent API in sell-value addons so other addons can get the info. You have to have an addon that provides this API for it to work. TeжubԎ Ҩ Ѡ 02:29, 23 October 2008 (UTC)