Subject:
|
Re: Mechanics of proxy bidding?
|
Newsgroups:
|
lugnet.market.theory
|
Date:
|
Thu, 28 Oct 1999 19:44:18 GMT
|
Viewed:
|
338 times
|
| |
|
|
Steve Demlow wrote:
>
> I'm trying to figure out how to do proxy bidding (with multiple instances of
> a lot). My current assumptions are:
>
> - Each instance of a lot stores the following information: the bidder, the
> max. proxy bid placed by that bidder, and the timestamp of the bid (and
> of course the current price of the instance)
> - Instances are stored/listed in order, where the primary order is
> determined by asking price and secondary order is determined by timestamp
> just like AucZILLA, and my software, currently do it). "Heavier" (pricier,
> older) instances sink to the "bottom" of the list.
> - Bid negotiation rules are as follows:
> - Higher price wins
> - If prices are the same, older timestamp wins (so older proxy bids
> win out against newer bids of the same value)
> - As soon as a bump occurs, the instances are re-ordered if necessary to
> maintain the ordering described above.
> - If a bid is bumped, and there was a higher proxy bid on that instance,
> the proxy bid is automatically re-submitted to the system, just as if the
> bidder had submitted it (except that the older timestamp stays intact).
>
> This does not always achieve the desired outcome. Consider this example
> with two instances of a lot ("foo"); the second price column denotes
> current, not asking, price.
>
> Starting state (A's bid is older than B's):
>
> foo 1.00} .50 B
> foo .80} .50 A
>
> C bids 0.60, bumping B, and the instances reorder, based on price:
>
> foo .80} .50 A
> foo .60} .60 C
>
> B rebids 1.00, bumping A, and the instances reorder, based on timestamp:
>
> foo .60} .60 C
> foo 1.00} .60 B
>
> A rebids .80, bumping C, and the instances reorder, based on price:
>
> foo 1.00} .60 B
> foo .80} .70 A
>
> A's bid was older than B's, so A shouldn't end up paying more than B. What
> am I missing here?
>
> I'm hoping that Todd in particular will offer some hints about this, but
> other insights are welcome as well.
One thing you need to decide is if a proxy need only meet the bid which
causes it to be re-submitted, or to beat it by a bid increment if
possible. It looks like you're planning on the 2nd.
The way I would be inclined to handle the situation is to temporarily
sort the bids by the maximum possible bid (sorting 2nd by time). Then
you know which bid is going to get bumped. Remember it's amount. Now
re-sort by current standing bid value (and 2nd by time). Now increase
all standing bids to the amount your proxy system requires (one bid
increment if possible, or just equal). So in this case (I'm assuming the
left hand bids are the proxies) after step 1 you have:
C 0.60 0.00
A 0.80 0.50
B 1.00 0.50
So you know C's bid will be bumped. Since you are using the proxy must
beat the bid, the new minimum bid is 0.70, so now you re-order by
current bid:
B 1.00 0.50
A 0.80 0.50
And increment the bids as necessary:
B 1.00 0.70
A 0.80 0.70
Now what happens if C bids 0.85, which should fail since it isn't one
bid increment above A's bid, we need to add an extra finagle before
sorting the new bid into step 1, check if it will be enough to beat the
lowest proxy. If not, automatically sort it to the bump position,
continue step 2 and 3 as above. A refinement of step 3 is that the new
minimum bid price probably should be the same for everyone, so you set
it to the lower of
1. equal to the bumped bid or one increment higher than the bumped
bid
2. the lowest proxy bid which will still stand
So now in our example:
Step 1: C 0.85 0.00 -> new min bid: 0.80
A 0.80 0.70
B 1.00 0.70
Step 2: B 1.00 0.70
A 0.80 0.70
Step 3: B 1.00 0.80
A 0.80 0.80
Now C decides to bid 0.90:
Step 1: A 0.80 0.80 -> new min bid: 0.90
C 0.90 0.00
B 1.00 0.80
Step 2: C 0.90 0.00
B 1.00 0.80
Step 3: C 0.90 0.90
B 1.00 0.90
One advantage of doing it this way is that if someone has multiple bids,
you don't put them in a bidding war. Lets say we have 4 equivalent lots
with the following bids:
Step 0: C 1.80 0.50
B 2.00 0.50
B 2.00 0.50
A 1.50 0.50
D comes along and bids 1.60:
Step 1: A 1.50 0.50 -> new min bid: 1.60
D 1.60 0.00
C 1.80 0.50
B 2.00 0.50
B 2.00 0.50
Step 2: D 1.60 0.00
C 1.80 0.50
B 2.00 0.50
B 2.00 0.50
Step 3: D 1.60 1.60
C 1.80 1.60
B 2.00 1.60
B 2.00 1.60
Other systems, by initally bumping C's bid because it is the newest,
would raise C's bid to 1.80 and B's bids to 1.90 (1.80 if you just
require proxies to match bids).
Of course I've probably forgotten some niggling point.
--
Frank Filz
-----------------------------
Work: mailto:ffilz@us.ibm.com (business only please)
Home: mailto:ffilz@mindspring.com
|
|
Message has 1 Reply:
 | | Re: Mechanics of proxy bidding?
|
| (...) Yep, I should have been more clear about that: I am seeking to emulate the behavior of the AucZILLA software as closely as possible. So that means that proxy bidding will usually raise the price above the competing bid, not just match it. (...) (25 years ago, 30-Oct-99, to lugnet.market.theory)
|
Message is in Reply To:
| | Mechanics of proxy bidding?
|
| I'm trying to figure out how to do proxy bidding (with multiple instances of a lot). My current assumptions are: - Each instance of a lot stores the following information: the bidder, the max. proxy bid placed by that bidder, and the timestamp of (...) (25 years ago, 28-Oct-99, to lugnet.market.theory)
|
4 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
