2 ms·

You probably should listen to this advice. (Searching through every bid is going to be painful). The highest unique bid complicates things slightly.. All of y

You probably should listen to this advice. (Searching through every bid is going to be painful). The highest unique bid complicates things slightly.. All of your bids have 3 possibilities compared to the current highest bid. (lower, same, higher). LOWER: lower is easy - it's not a winner. Except for this scenario: 1. $10 --> Becomes highest unique 2. $9 --> lower, not a winner 3. $10 --> Duplicate with no.1 no.2 ($9) is now highest unique SAME: Same is easy - your old highest unique no longer is a win. HIGHER Higher becomes a win - UNLESS there's already 2 (or more) bids at that value. Some thoughts - perhaps store three lists and a value? sorted list of duplicates lower than the Highest Unique Value (HUV) sorted list of duplicates higher than the HUV sorted list of uniques Current HUV Take a new bid. Compare to the HUV: Lower: not a winner. SAME: not a winner - HUV updated to next highest unique. value appended to duplicates list. HIGHER: compare to Higher duplicates list. If not in there - update as HUV - winner. Behind the scenes - I assume you're logging each bid, details, etc.. You wouldn't have to wait to do this in order to return a result. Is that understanding your issue?

owkaye 18y ago
Thanks for the HUV acronym whatusername, it makes describing things easier. I think you have a pretty good understanding of the system now. I'll reword your description in an effort to clarify, and if this is not the way you understand it please tell me so I can try to make a better explanation. Every bid has 3 possibilities compared to the current HUV: lower, same, higher. LOWER = not a winner simply because it's lower SAME = not a winner because it's a duplicate HIGHER = additional checking required: HIGHER and DUPLICATE = not a winner HIGHER and UNIQUE = winner! That's basically how to determine the status of a new bid. As far as programming tasks are concerned, the value of each new bid must be added to the list of existing bids if it's not already there. Then the status of the new bid must be updated ... and if this changes the status of the HUV, the new HUV must be determined: Determining a new HUV is where sorting becomes necessary, but I think this may be the ONLY place where a sort is required. >>> Behind the scenes - I assume you're logging each bid, details, etc.. You wouldn't have to wait to do this in order to return a result. <<< Yes, logging each bid is important but previously I failed to 'separate' the logging task from the process described above. If the HTTP server can log the cookie value (bidderID) and the post data (bidValue) itself that's all I may need. On the other hand this assumes a new connection to the HTTP server every time a bid is posted -- and if I use Ajax to pass data back and forth without creating these new connections I will also need a separate app to take care of the logging.

owkaye 18y ago

Thanks for the HUV acronym whatusername, it makes describing things easier. I think you have a pretty good understanding of the system now. I'll reword your description in an effort to clarify, and if this is not the way you understand it please tell me so I can try to make a better explanation. Every bid has 3 possibilities compared to the current HUV: lower, same, higher. LOWER = not a winner simply because it's lower SAME = not a winner because it's a duplicate HIGHER = additional checking required: HIGHER and DUPLICATE = not a winner HIGHER and UNIQUE = winner! That's basically how to determine the status of a new bid. As far as programming tasks are concerned, the value of each new bid must be added to the list of existing bids if it's not already there. Then the status of the new bid must be updated ... and if this changes the status of the HUV, the new HUV must be determined: Determining a new HUV is where sorting becomes necessary, but I think this may be the ONLY place where a sort is required. >>> Behind the scenes - I assume you're logging each bid, details, etc.. You wouldn't have to wait to do this in order to return a result. <<< Yes, logging each bid is important but previously I failed to 'separate' the logging task from the process described above. If the HTTP server can log the cookie value (bidderID) and the post data (bidValue) itself that's all I may need. On the other hand this assumes a new connection to the HTTP server every time a bid is posted -- and if I use Ajax to pass data back and forth without creating these new connections I will also need a separate app to take care of the logging.