Confused about Leu bidding

My suspicion is the system tracks pre-bids vs live bids in separate tables. This makes sense since the pre-bids generate far less performance/concurrency concerns than the live portion. When you update your pre-bid, it just increases your current pre-bid while keeping the timestamp (which may be necessary when resolving conflicts).

During the live stage, each bid is entered into another table. It's then possible to read the bids with the appropriate data concurrency model without a transaction, or if this is some in-memory data structure, a short read-lock. This maximizes the performance.

The ability to view bidding history was obviously added after this system was created. Since not all bidding records were necessary to compute the highest bidder, the programmer was only able to output the existing rows.

Therefore, my previous "automatic" bid of 550 is not listed because it occurred during the pre-bid portion, and the system was able to calculate the maximum bid easily given the current table contents. There's no need for a separate row except for data reporting, which as I mentioned was clearly added afterwards.

However, the live portion does require a more robust system requiring that two-step process, and therefore each bid has its own row that shows in the summary.

There's no bug here other than lazy programming.

 

Log in or Sign up to hide this ad.

Let's assume that a "live bid" is defined as a bid placed directly by a bidder on a specific coin at a specific time while the auction is still ongoing. It is not a "max bid." Let's also assume that a live bid, if it's higher than the currently winning bid by at least the required increment, becomes the new currently winning bid. E.g., if a coin's currently winning bid is 500 CHF and I place a live bid of 1000 CHF, then my bid becomes the currently winning bid.

Based on these definitions and assumptions, the computer algorithm is likely to have done the following:

0. Currently winning bid is 500 CHF (or 550 CHF -- doesn't matter which).
1. Bidder 4 places a live bid of 605 CHF.
2. Is this bid higher than the current bid by the required increment?
- if no, ignore the bid
- if yes, display this bid as the currently winning bid
3. Sequentially search all current bidders' maximum bids to see if any of them is higher than 605 CHF by at least the increment of 50 CHF
- if none, than leave 605 CHF displayed as the currently winning bid
- if yes increment the currently winning bid amount to 655 CHF for the first max bidder found.
4. Repeat step 3. until there are no more bids higher than the currently winning bid (by the required increment).

If this is accurate, then after the displayed bid of 605 CHF, every subsequent bid that was displayed would be of the amount XX5 CHF.

So if there were some bids displayed such as 650 CHF, or 700 CHF, my putative algorithm is either not the one being used, or there was a bug in the software.

 

I believe the algorithm is different. You can divide it into two parts - pre-bid and live.

Pre-bid
Given a bid for x CHF on item foo:
Is the bid higher than the current?
No - ignore the bid
Yes - Has this user already placed a bid for the item?
No - Enter the bid as a new row in the table
Yes - update the existing bid for the new amount

The logic that displays the current max is separate.
Choose the top two rows by price.
Is the lower value plus the bid increment greater than the higher value?
No - display the lower value plus the bid increment
Yes - display the higher value

Live
Given a bid for x CHF on item foo:
Enter the bid into the system
Validation that the bid is at least one increment higher than the current is done on the client, though presumably it's done again here for data security.

The logic that displays the current max:
Choose all the live rows and the top pre-bid row.
Similar logic to the above, but factoring in pre-bids and live bids.

 

Altough I do not know for sure how their bidding log works, here is how I read it:

Bidder 4 755 CHF 27-Feb-22 10:59:01
kirispupis 750 CHF 27-Feb-22 10:59:01
kirispupis 650 (750) CHF 27-Feb-22 10:58:48
Bidder 4 605 CHF 27-Feb-22 10:58:48
kirispupis 550 (750) CHF 18-Feb-22 01:04:43 <--
Bidder 2 500 CHF 18-Feb-22 01:04:43
Bidder 2 400 (500) CHF 15-Feb-22 03:47:59
Bidder 3 380 CHF 15-Feb-22 03:47:59
Bidder 2 360 (500) CHF 15-Feb-22 03:47:51
Bidder 3 340 CHF 15-Feb-22 03:47:51
Bidder 2 320 (500) CHF 15-Feb-22 03:47:32
Bidder 3 300 CHF 15-Feb-22 03:47:32
Bidder 2 220 (500) CHF 15-Feb-22 03:47:29
Bidder 3 200 CHF 15-Feb-22 03:47:29
Bidder 2 160 (500) CHF 15-Feb-22 03:47:26
Bidder 3 150 CHF 15-Feb-22 03:47:26
Bidder 2 110 (500) CHF 14-Feb-22 17:41:54
Bidder 3 100 CHF 14-Feb-22 17:41:54
Bidder 2 55 (500) CHF 09-Feb-22 03:00:08
Bidder 1 50 CHF 03-Feb-22 14:36:55

The system simply doesn't show the intermediate bids that are only calculated and not available as real data.

Leu web auctions are "timed auctions", meaning that they don't have a live portion, although their "live view" with the changing lots may make you feel so. All bids are pre-bids.

 

I never pre-bid my loss is someone's gain. Out of sight out of mind if I can't watch the bidding process my interest is not there to begin with. Good luck.

 

You're right. That's where the excitement comes in. The "Auction Fever" !!