#33 winning bids sorted first supersede earlier bids

[ksf]

Auctions are sorted by current status and winning bid already placed goes first in sorting (mentioned in the history log of 2004-12-15).
But other auctions (no bid placed) ending before this winning auction, are run after and are therefore missed. Because it bids after the item has ended (bug report attached).
This seems to be very basic and I am maybe missing something but I don't understand this sorting by status ignoring earlier ending auctions.

[Michael S.]

The mechanism of sorting auctions is based on

1. current status (i.e. you already placed a bid and are winning)
2. end time
   (see auctioninfo.c line 308 ff).
   Is seems to be some kind of prioritising of auctions you have already bid on.
   To avoid this problems use only esniper to bid on actions.

In the future a setting in the auction-file could be implemented (feature request) e.g.

Sort=[...|WinTime|Time]

None|Empty|WinTime=Traditional sorting
Time=Only by endtime

[ksf]

The logic of prioritising winning bids was introduced in 2004 and has not been challenged over the past 15 years it seems.
To my opinion this logic is debatable: end time is more important than whether the auction has a winning bid or not to determine the order.
What do you mean by "bidding on actions"? do you mean I should not bid manually, this is what I do now, I only use esniper to avoid that it prioritises my winning bids and misses others even if they finish earlier.
Very strange feature, an option would make sense, or even change this logic that should apply only when the end time is the same but the end time order should be considered first I think.

    if (!strcmp(a1->auction, a2->auction))
        return 0;

    if (a1->endTime == a2->endTime)
       if (a1->winning != a2->winning)
            return a1->winning > a2->winning ? -1 : 1;
        return (int)((a1->price * 100.0) - (a2->price * 100.0));

    return (int)(a1->endTime - a2->endTime);

[Bodo]

The sorting was implemented by the original author of esniper and is intentional.

The logic was chosen to make sure you don't end up paying for more articles than you wanted to buy. (And maybe to keep the algorithm simple.)

Let's take a very simple example: Assuming you want to buy one article only and you already have a winning bid for one auction. If esniper successfully bids on a different auction with an earlier ending time you have to buy this article. Later you might also win the auction for the article with the existing bid without esniper doing anything. In this case you have to buy two articles.

Of course there are possibilities for improving the algorithm.

When you tell esniper that you want a quantity >1, esniper could count the auctions with winning bids, and if these are less than quantity then it can bid on different auctions first without waiting for the result of an already winning bid.

This could be implemented without any danger for a user having to pay too much. It will make the sorting algorithm a bit more complicated though which will require some testing.

You can also argue that you don't care buying more articles than you wanted for a minimal price, e.g 1USD or 1EUR. The difficulty is that esniper doesn't know the maximum bid you entered manually. If the current bid is 1 it may go up later after possibly winning another auction by esniper's bid.

I know that sometimes it might be useful to bid a minimal amount in order to disable a buy-it-now option.

It would be possible to add a configuration setting e.g. ignore_winning_bids to switch the sorting order if the user wants this. The default setting should be disabled. (A boolean setting is easier to handle with the existing option and config file parsing function than a string option like sort=something.)

When using this new option it would be the user's responsibility to make sure he doesn't manually bid high amounts on some auctions.

Bodo

[Bodo]

Ticket moved from /p/esniper/bugs/768/
(changed from bug to feature request)

[ksf]

Thanks Bodo for these explanations of the original logic. Then:

• If quantity >= # autions monitored, is there any reason to adopt this approach?
• The winning bid situation can change at any time, the sorting would need to be updated in real time to be effective, it is not the case at the moment I believe

Anyway I can agree with you the option is a way to allow to switch off this original behaviour, I would rather call it prioritise_winning_bids and have it enabled (if this is the default behaviour current authors support) to be clear on the fact there is currently an active filtering in the sorting.

[Bodo]

Of course it is possible to implement improvements. You are free to create a patch.

I think normally the quantity is reduced internally for auctions already won, but there is am option to change this. (Check the source to be sure.)
The correct condition might depend on the option to automatically reduce the quantity.
It could be:

number of winning bids < reduced quantity

or

number of auctions won + number of winning bids < original quantity

The condition

 quantity >= # autions monitored

might cover only the specific case when I want to win all specified auctions. (If enough offers are available I usually specify more auctions than the required quantity because I want to wait for the next auction if the price gets too high.

I guess the calculation of the time to sleep should be changed to correctly check for winning bids:

If there are auctions with winning bids, the first auction in the queue should be the one ending first of these .

The time to sleep should be calculated from both the first auction with a winning bit and the first one of all active auctions. The minimum of these should be chosen. This way esniper can update the check for winning bids in a timely manner.

[ksf]

I would keep the algorithm as simple as possible, I am not sure it's worth developping a functionality that would be used by less than 1% of the users (I say so because it seems no one has requested it over the past 15y and personally I don't need it either).
My suggestion would just be to have a flag to disable this winning bid priority, and leave it on by default to have the minimum disruption. This is very simple. What do you think?

[ksf]

I'd be happy to submit a commit if the project was on github but I am not familiar with sourceforge. If you think the proposed option will be accepted for the next release I can invest some time to learn C and submit a patch, if not that's fine, now that I am aware of this feature I don't bid manually on any item to avoid this behavior.

[Bodo]

There were other reports about this behavior in the past, but the answer was always "don't bid manually if you want to use esniper". An option to change this might be useful for others as well.
I don't see a problem with integrating a modification that allows more options for the user.

I clearly see two separate tasks that can be chosen to be implemented or not independently from each other:

1. an option to sort strictly by ending time ignoring existing winning bids
2. an improved calculation of the sleep time until the next check of the auction list if auctions with winning bids are prioritized

When you go to the project's "Git" tab (https://sourceforge.net/p/esniper/git/ci/master/tree/) you should find a "Fork" tool on the left side (https://sourceforge.net/p/esniper/git/fork). Probably this is similar to a fork on GitHub. I also see a "Merge Requests (0)" there, I guess this is similar to GitHub's pull requests, but I don't know how you would create a merge request. Maybe you have to fork the project first. I suggest to create a new branch for your changes and to keep master for pulling from the main repository.

(You could also import the project on GitHub, but in this case you might have to send patch series instead of an creating merge request.)

I hope it won't get too difficult if you have to learn C first.

[ksf]

I have pushed the feature in my fork Branch: feature/win_sort_option
This is I think implementing the point 1. above, I have done some basic tests and to me it does what it is supposed to.
Let me know.

[ksf]

I requested a merge of my branch into master, if I should do things differently let me know

[ksf]

@Bodo any interest in my new option?

[Michael S.]

What I'm missing personally, is a message to the user, which inform about the risk of buying more items than expected.

[ksf]

The risk of missing an item the user absolutely needs because of the current default behaviour is more of an issue I think. The user can miss an auction because he is bidding on another one without any explanation. The opportunity cost can be huge in current behaviour while if the user is bidding manually he is well warned by eBay that his action is binding.

[Michael S.]

You may split your auction file into two. One contains the item you want to buy urgently and the second with all other items. Then run two instances of esniper:

$ nohup esniper -c yourconfig.cfg auctionfile1 > 1.out &
$ nohup esniper -c yourconfig.cfg auctionfile2 > 2.out &

[ksf]

Yes that works, anyway both of us understand the current behaviour and can circumvent any unwanted effect.

[Michael S.]

@bomm & @leggewie: Your vote ? Do we implement this new feature ?

[Bodo]

The code looks OK. User leggewie has not been active here for several years.

[Rolf]

My role in esniper has never been that of a coder

[ksf]

What is your conclusion?
To restate my opinion, I think it is an option which is not disruptive as the defaults stay the same, therefore quite safe to implement. It adds an alternative to the default feature which is possibly damaging. It gives the option to the power users to control this behaviour.

[Michael S.]

Merged.

[ksf]

When is a new release with this feature expected? thanks

[Michael S.]

Currently the feature is only available from the git repository.

[ksf]

I've been waiting for an update to reflect it in distro packages, when can we expect the next official release? thanks!