SMTP Error

OT Programming Conundrum - But where else can I find such excellent help?



Hi Mike,

As others indicated, I still think that you are approaching the solution
from the wrong direction, and after reading the instructions for your
auction this is even more obvious. Why do you need to know the number of
possible combinations at all?=20

An error in your reasoning may be that you are treating all your =
constraints
without consideration for the chronological/logical order of the =
auction,
nor with the constraints or conditions created through the interactions =
or
effects of other users (and their consequences for a bidder who has a =
MaxBid
that is not yet reached and therefore should automatically augment).=20

On the other hand some variables only apply at the end of the auction - =
for
example RESERVE. In other words, most combinations exclude each other =
right
off the start, so there is absolutely no need anymore to do any further
computation with them, and other conditions or cases will apply later or =
in
addition. Your approach may be at the same time too simple and too
complicated.=20

One way to narrow down the combinations and constraints is to design a
simple use-case scenario=20


You can break your auction down into 3 phases
1. Start
2. Upbidding
3. End


CurrentHigh =3D MinBid

1.) A new bid:

IF IncomingBid < MinBid
---> Save, insult and Exit

ELSEIF IncomingBid =3D CurrentHigh
---> Error - the system should require that a new bid is at least
one increment higher than the CurrentHigh.

ELSE=20
---> go to Phase 2 (now IncomingBid=3DCurrentHigh)




2.) IF IncomingBid > CurrentHigh
---> CHECK MaxBid of all bidders that are still in the auction
=09
WHILE IncomingBids <=3D MaxBid=20
---> RAISE all.IncomingBids=20
UNTIL=20
someones.IncomingBid =3D allothers.MaxBid+increment *

---> someones.IncomingBid =3D CurrentHigh=20

ELSE --> outbid


( * this requires an additional rules to avoid conflicts
with 2 or more bidders have the same MaxBid that qualifies them for
CurrentHigh. For example based on the time when the bid/MaxBid was =
initially
submitted)



3.) Completion of Auction (T=3D0)

IF CurrentHigh < Reserve=20
---> Lost auction, no sales --> Exit
ELSE=20
---> CurrentHigh =3D WINNER!=20



So regarding your combinational problem the possible situations are:

Phase 1: A>B(Exit),A=3DC(Error),A>C
Phase 2: A<C,A=3DC,D<C(Exit),D=3DC,D>C + rule to prevent conflict
Phase 3: T=3D0,C>E(Wins),C=3DE(Wins),C<E(Exit)

And even they could be subgrouped further so that the logic becomes even
clearer.

Applying=20
A IncomingBid
B MinumumBid
C CurrentHigh
D MaxBid
E Reserve
T TimeLeft


This is of course just an example with no guarantee that it covers your
specific situation (nor that it is accurate & complete at all). Very =
likely
that I still missed something here and there and elsewhere, but I hope =
you
get the idea.=20

Take care,

Markus








-----Original Message-----
From: [email protected] [mailto:[email protected]] On =
Behalf
Of Signature House
Sent: Mittwoch, 9. M=E4rz 2005 20:40
To: 'Miva-Users'
Subject: RE: [meu] OT Programming Conundrum - But where else can I find =
such
excellent help?

Markus

Great! Give a man a fish and eats for a day, but teach him how to fish =
and
he eats for life (or something like that).

Thanks so much for naming this thing for me.

On the rest, I think I'm going to disagree with you here, at least at =
first
glance.

In my initial statement I said I had 4 variables (ABCD) to deal with and
that I wanted to compare each to all of the others. I arrived at a =
unique
set of 729 potential comparisons by a 2 step use of combinations and
permutations.

First step: How many potential comparisons?:
Since A=3DB is equivalent to B=3DA, A>B equivalent to B<A, and A<B =
equivalent to
B>A, order was not important. Therefore, I'm looking at a combination,=20
B>not a
permutation; and since A=3DA, B=3DB, ... are also not important, it's =
without
replacement. So, I have 6 possible comparisons
(A::B,A::C,A::D,B::C,B::D,C::D). If order was important, then I'd have =
been
talking about a permutation, also without replacement and there would =
have
been 12 comparisons(A::B,B::A,...).

Second step: How many potential results?:
Looking at the 6 comparisions that I have =
(A::B,A::C,A::D,B::C,B::D,C::D),
you can see that I have 6 holes to fill, each with one of 3 operators =
(<, =3D,
>). Since order does matter, I now have a permutation, albeit a some=20
>what
unusual one since replacement does occur, ie, 3 items taken 6 at a time. =
The
solution is 3 to the 6th power, or 729 potential, unique results.

Applying the same steps to the 5 variable problem gives me 10 =
comparisons
and 59,049 potential, unique results.

Your list of 54 combinations is missing some items, for example, <<<<

Having said that, and remembering that this response is just after a =
first
glance, I may very well be all wet. If so, I certainly want to find it =
out
now.

I'll certainly give your response a lot more study, especially the code =
- it
really looks interesting.

Many thanks


Mike McBee
Signature House
[email protected]
www.signaturehouse.net
304-842-3386

-> -----Original Message-----
-> From: [email protected] [mailto:[email protected]]On
-> Behalf Of MvMarkus
-> Sent: Tuesday, March 08, 2005 09:20 PM
-> To: 'Signature House'; 'Miva-Users'
-> Subject: RE: [meu] OT Programming Conundrum - But where else can I=20
-> find such excellent help?
->
->
-> Hi Mike
->
-> That is called Logic or constraints programming and more specifically =

-> a search. Languages like Prolog and Mozart and a few others are=20
-> designed for that, if you are interested in this you may want to take =

-> a look at the mozart tutorial to see how they handle that:
-> <A HREF ="http://www.mozart-oz.org/documentation/fdt/index.html or=20">http://www.mozart-oz.org/documentation/fdt/index.html or=20</A>
-> <A HREF =/"http://www.mozart-oz.org/papers//">http://www.mozart-oz.org/papers/</A>.
->
-> The way is to first reduce logically or mathematically the number of=20
-> possible combinations and then get the rest, if necessary through=20
-> brute force.
->
-> I'm afraid however this won't give you a quick answer....
->
-> With 5 variables, you actually don't have that many possibilities at =
all.
-> The mistake is to think of x power y, because in fact your choices=20
-> are much more limited because a>b is the same as b<a and if a=3Db and =

-> c=3Dd then is a=3Db=3Dc
->
->
->
->
-> A=3DC B=3DC ---> A,B=3DC
-> A<C B<C ---> A,B<C
-> A>C B>C ---> A,B>C
-> A=3DD B=3DD C=3DD ---> A,B,C=3DD
-> Etc.
->
-> So if you forget for a moment the variables, but instead you look at=20
-> the operators, you get
->
-> A=3DB=3DC=3DD=3DE ---> =3D=3D=3D=3D
-> A<B=3DC=3DD=3DE ---> <=3D=3D=3D
-> A>B=3DC=3DD=3DE ---> >=3D=3D=3D
-> A=3DB<C=3DD=3DE ---> =3D<=3D=3D
-> A=3DB>C=3DD=3DE ---> =3D>=3D=3D
-> A=3DB=3DC<D=3DE ---> =3D=3D<=3D
-> ... Etc.
->
-> In form of a matrix, that looks like this:
->
-> 1 2 3 4
-> 1 =3D =3D =3D =3D
-> 2 < =3D =3D =3D
-> 3 > =3D =3D =3D
-> 4 =3D < =3D =3D
-> 5 < < =3D =3D
-> 6 > < =3D =3D
-> 7 =3D > < =3D
-> 8 < > < =3D
-> 9 > > < =3D
-> 10 =3D =3D < =3D
-> 11 < =3D < =3D
-> 12 > =3D < =3D
-> 13 =3D < > =3D
-> 14 < < > =3D
-> 15 > < > =3D
-> 16 =3D > > =3D
-> 17 < > > =3D
-> 18 > > > =3D
-> 19 =3D =3D =3D <
-> 20 < =3D =3D <
-> 21 > =3D =3D <
-> 22 =3D < =3D <
-> 23 < < =3D <
-> 24 > < =3D <
-> 25 =3D > < <
-> 26 < > < <
-> 27 > > < <
-> 28 =3D =3D < <
-> 29 < =3D < <
-> 30 > =3D < <
-> 31 =3D < > <
-> 32 < < > <
-> 33 > < > <
-> 34 =3D > > <
-> 35 < > > <
-> 36 > > > <
-> 37 =3D =3D =3D >
-> 38 < =3D =3D >
-> 39 > =3D =3D >
-> 40 =3D < =3D >
-> 41 < < =3D >
-> 42 > < =3D >
-> 43 =3D > < >
-> 44 < > < >
-> 45 > > < >
-> 46 =3D =3D < >
-> 47 < =3D < >
-> 48 > =3D < >
-> 49 =3D < > >
-> 50 < < > >
-> 51 > < > >
-> 52 =3D > > >
-> 53 < > > >
-> 54 > > > >
->
->
-> which are effective 54 combinations.
->
-> With a recursive function which interrupts itself as soon as a value=20
-> returns false, you can actually get a result quite quickly.
->
-> Enough of all that theory, here some more practical code that is=20
-> actually
-> tested: If you sort the values first, as Bill suggested, you can even =

-> reduce the number of iterations much further. You can use the=20
-> following function for as many combinations / variables as you like.=20
-> (The script can be shortened a bit, because it has some rudimentary=20
-> things in it from the original version with with 3 different=20
-> operators).
->
-> // You have 11 variables:
->
-> <MvASSIGN NAME =3D "l.var" INDEX=3D"1" VALUE =3D "1880" > <MvASSIGN =
NAME =3D=20
-> "l.var" INDEX=3D"2" VALUE =3D "15" > <MvASSIGN NAME =3D "l.var"=20
-> INDEX=3D"3"VALUE =3D "75" > <MvASSIGN NAME =3D "l.var" INDEX=3D"4" =
VALUE =3D=20
-> "13450" > <MvASSIGN NAME =3D "l.var" INDEX=3D"5" VALUE =3D "1544" >=20
-> <MvASSIGN NAME =3D "l.var" INDEX=3D"6" VALUE =3D "15.44" > <MvASSIGN =
NAME =3D=20
-> "l.var" INDEX=3D"7" VALUE =3D "1880" > <MvASSIGN NAME =3D "l.var" =
INDEX=3D"8"=20
-> VALUE =3D "15" > <MvASSIGN NAME =3D "l.var" INDEX=3D"9"VALUE =3D =
"4755" >=20
-> <MvASSIGN NAME =3D "l.var" INDEX=3D"10" VALUE =3D "100" > <MvASSIGN =
NAME =3D=20
-> "l.var" INDEX=3D"11" VALUE =3D "1544" >
->
-> // ... And 2 operators:
-> <MvASSIGN NAME =3D "g.op" INDEX=3D"1" VALUE =3D "=3D" > <MvASSIGN =
NAME =3D=20
-> "g.op" INDEX=3D"2" VALUE =3D "<" >
->
->
-> <MvASSIGN NAME =3D "l.result" VALUE =3D "{ loop(
-> 1,miva_array_deserialize(sort(l.var)),l.var,'') }" >
->
->
<MvEVAL EXPR =3D "{ l.result }" >
->
Iterations: <MvEVAL EXPR =3D "{ g.counter }" >
->
->
->
-> <MvFUNCTION NAME =3D "sort" PARAMETERS=3D"num" STANDARDOUTPUTLEVEL =
=3D=20
-> "html,text,compresswhitespace"> // this is just the sorting script
->
-> <MvASSIGN NAME =3D "l.a" VALUE =3D "1" >
-> <MvWHILE EXPR =3D "{ l.num[l.a] }">
-> <MvASSIGNARRAY NAME =3D "l.sorted" VALUE =3D "{ l.a }" >
-> <MvMEMBER NAME=3D"{ padl( gettoken(l.num[l.a],'.',1),10,'0') $
-> padr( gettoken(l.num[l.a],'.',2),5,'0') }">
-> <MvDIMENSION INDEX=3D"{ miva_array_max(=20
-> miva_variable_value('l.sorted:'$padl(
-> gettoken(l.num[l.a],'.',1),10,'0')$padr(
-> gettoken(l.num[l.a],'.',2),5,'0')))+1 }">
-> </MvASSIGNARRAY>
-> <MvASSIGN NAME =3D "l.a" VALUE =3D "{ l.a+1 }" > </MvWHILE> =
<MvFUNCRETURN=20
-> VALUE=3D"{ miva_array_deserialize( l.sorted )}"> </MvFUNCTION>
->
->
->
-> // The main recursive function
->
-> <MvFUNCTION NAME =3D "loop" PARAMETERS=3D"step,sorted,num,final"
-> STANDARDOUTPUTLEVEL =3D "html,text,compresswhitespace">
->
-> <MvIF EXPR =3D "{ l.step EQ miva_array_max(l.num) }"> <MvFUNCRETURN=20
-> VALUE=3D"{ l.final }"> </MvIF>
-> <MvASSIGN NAME =3D "l.p" VALUE =3D "1" >
-> <MvWHILE EXPR =3D "{ l.p LE 2 }">
-> // just a counter to get the number of iterations.
-> <MvASSIGN NAME =3D "g.counter" VALUE =3D "{g.counter+1 }" >
-> <MvIF EXPR =3D "{ calc( l.p,l.num[ l.sorted[l.step]] , l.num[
-> l.sorted[l.step+1]]) }" >
-> <MvASSIGN NAME =3D "l.final" INDEX=3D"{l.step}" VALUE =3D
-> "{l.num[ l.sorted[l.step]] $ g.op[l.p]$l.num[ l.sorted[l.step+1]] =
}" >
-> <MvFUNCRETURN VALUE=3D"{ loop(l.step+1,l.sorted,l.num,l.final
-> ) }">
-> </MvIF>
-> <MvASSIGN NAME =3D "l.p" VALUE =3D "{ l.p+1 }" >
-> </MvWHILE>
->
-> <MvFUNCRETURN VALUE=3D"{ l.final }">
-> </MvFUNCTION>
->
->
-> // a little helper:
->
-> <MvFUNCTION NAME =3D "calc" PARAMETERS=3D"iteration,var1,var2"
-> STANDARDOUTPUTLEVEL =3D "html,text,compresswhitespace"> <MvIF EXPR =
=3D "{=20
-> NOT fmod(l.iteration,2) }" >
-> <MvFUNCRETURN VALUE=3D"{ l.var1 LT l.var2}"> <MvELSE>
-> <MvFUNCRETURN VALUE=3D"{ l.var1 EQ l.var2}"> </MvIF> </MvFUNCTION>
->
->
->
->
-> /////////////////////////////////////////////////////
->
->
-> This returns:
-> =
15=3D15,15<15.44,15.44<75,75<100,100<1544,1544=3D1 544,1544<1880,1880=3D
-> 1880,1880<4
-> 755,4755<13450
-> Iterations: 17
->
->
-> /////////////////////////////////////////////////////
->
->
-> I have not the slightest clue if this has any meaning for your=20
-> auction script, but it was fun - all the good stuff is in it,=20
-> recursive function calls, nested array indices, sorting through=20
-> structures, functionreturns for IF-conditions etc... You have to love =

-> mivascript, especially if ...
->
->
->
->
-> ...it can get shorter:
->
-> <MvASSIGN NAME =3D "l.values" VALUE =3D "{ sort(l.var) }" >
->
-> <MvASSIGN NAME =3D "l.a" VALUE =3D "1" >
-> <MvWHILE EXPR =3D "{ l.values[l.a+1] }">
->
-> <MvIF EXPR =3D "{ l.var[l.values[l.a]] LT l.var[l.values[l.a+1]] }" =
>
-> <MvASSIGN NAME =3D "l.result" INDEX=3D"{l.a}" VALUE =3D "{ =
l.values[l.a]=20
-> $'<'$ l.values[l.a+1] }" >
-> <MvELSE>
-> <MvASSIGN NAME =3D "l.result" INDEX=3D"{l.a}" VALUE =3D "{ =
l.values[l.a]=20
-> $'=3D'$ l.values[l.a+1] }" >
-> </MvIF>
-> <MvASSIGN NAME =3D "l.a" VALUE =3D "{ l.a+1 }" > </MvWHILE>
->
->
->
<MvEVAL EXPR =3D "{ l.result }" >
->
-> Which effectively returns the array indices of the original variables =

-> (the result is the same):
-> 2=3D8,8<6,6<3,3<10,10<5,5=3D11,11<1,1=3D7,7<9,9<4
->
-> As others said before me, you need to look into the requirements
-> (constraints) and cut the number of conditions down first that way.
-> Otherwise you end up like me writing 30 lines of fancy code when 10=20
-> simple ones do the trick.
->
->
->
-> Markus
->
->
->
->
->
->
->
->
->
->
->
-> -----Original Message-----
-> From: [email protected]
-> [mailto:[email protected]] On Behalf Of Signature House
-> Sent: Dienstag, 8. M=E4rz 2005 18:57
-> To: 'Miva-Users'
-> Subject: [meu] OT Programming Conundrum - But where else can I find=20
-> such excellent help?
->
-> I'm building an application where I need to perform an action=20
-> depending on the relationships (<,=3D,>) of 4 variables (A,B,C,D).
->
-> This gives me 6 comparisons (A::B, A::C, A::D,B::C,B::D,C::D) with a=20
-> total of 729 (3 to the 6th power) possible results, ranging from A<B, =

-> A<C, A<D,B<C,B<D,C<D through A>B, A>C, A>D,B>C,B>D,C>D.
->
-> Obviously, many of these 729 results are mathematically impossible=20
-> (eg, anything containing A=3DB,B=3DC,A>C) and could never occur.
->
-> I was able, semi-manually, to eliminate (I hope) all the impossibles=20
-> (654), leaving me with only 75 mathematically possible results.
->
-> Further examination turned up 50 results that were not possible in=20
-> the context of the application and 12 that were possible but had no=20
-> effect on the application, although both groups needed an error trap =
just
in case.
->
-> All told, I ended up with only 13 conditions where I had to program=20
-> an action - definitely much easier to deal with than the 729 I =
started
with.
->
->
-> Now, my problem - my employer wants to add a fifth variable (E) to=20
-> the mix.
-> This will give me 10 comparisons with a possible set of results=20
-> numbering
-> 59,049 (3 to the 10th power).
->
-> Just as I did with the 4 variables I need to eliminate all the=20
-> impossibles, but this is wayyyy to0 many for me to reduce using=20
-> semi-manual techniques.
->
-> Can anybody give me a link to something on the web that can help me?=20
-> I don't even know what it's called to start looking for it. I tried=20
-> "Truth table" in Google and got 168,000 hits, but nothing seemed=20
-> relevant.
->
-> Any suggestions?
->
-> Thanks
->
->
-> Mike McBee
-> Signature House
-> [email protected]
-> www.signaturehouse.net
-> 304-842-3386
->
->
->
->

OT Programming Conundrum - But where else can I find such excellent help?



Markus

-> Why do you need to know the number of possible combinations at all?

My reasons, mentioned earlier: completeness and robustness of the
application. And one I didn't mention, but just as important: flexibility.

There are laws (which vary from jurisdiction to jurisdiction, and which can
change over time) that cover the broad outlines of how auctions must be
conducted. However, within these broad outlines there are a lot of
variations that can occur. These details vary from auction house to auction
house. And over time, given the potential of business model and/or
management changes, and in response to legal changes and market pressures,
details can (and do) change within an auction house. Some houses even vary
the details based on where they are within a given auction cycle.

Some examples:

1) Reserves: Uniform Commercial Code (UCC) section 2-328 (3) states all
auctions are with reserve unless the goods are in explicit terms put up
without reserve (without reserve would be an 'absolute' auction). Does an
auction house have to reveal that there is a reserve? Do they have to
reveal, at any time, the amount of the reserve? Do they have to tell the
bidder that a reserve has been reached? Do they have to start the bidding at
the reserve? The UCC doesn't say one way or the other, so, absent any other
local laws that may be in force, it's up to the auction house.

Depending on the auction house's choices, I have either a 4 variable
scenario, and the Reserve can be dealt with at auction's end (as you've
mentioned), or the Reserve must be dealt with immediately at each bid and I
have the 5 variable situation.

2) How to treat a new bid that's between the Current High and the Current
Max:
I know of 2 common ways this is handled. a) I'll use eBay as an example,
since so many millions of people are familiar with it. If a bidder submits
this type of bid, then the previous bidder's High Bid is raised to either 1
increment above the new bidders max bid, or the previous bidder's max bid,
whichever is less. b) Same scenario, but a different outcome; the previous
bidder's High Bid is raised to MATCH the new bidder's max bid (no increment
is used). Strangely enough, eBay uses this method in their Live Auctions
section and this really confuse people who are used to their 'normal' way of
doing things.

Below you mention 3 phases
-> 1. Start
-> 2. Upbidding
-> 3. End
Fortunately, if you look at it just right (cockeyed & upside down), there is
no actual difference between Start and Upbidding, so generally there are
only 1. Bidding and 2. End. There may be a third, called, perhaps, 1.9. Near
End, if an auction house chooses to vary, say, how the handle reserves as
they get near the end of the auction.

You also said
-> ELSEIF IncomingBid = CurrentHigh
-> ---> Error - the system should require that a new bid is at least
-> one increment higher than the CurrentHigh.

I could write the system to make sure an incoming bid met this criteria, but
that doesn't mean they won't come in. We started out as a catalog only
auction, taking absentee bids by phone, mail, fax and in person before a
specified deadline. Then a live Sale Day was added, with live phone bidders
and, sometimes, a live audience. With the internet came absentee email
bidding and absentee bidding via our website, and now live sale day bidding
on eBay.

Some of these forms of bidding allow for immediate feedback (phone, in
person, live audience) so that we can tell a bidder no. eBay Live actually
calculates the next legal bid for the bidder and provides no way to vary
from it. With the other bidding procedures, no such immediate interaction is
possible. If I allow them into the system, then the system can handle
telling them. You might recall from my first post that I said there were 12
results that were possible but had no effect on the application, that's
where bids of this type fit in.

There's a heck of a lot more where this came from - haven't even got into
the differences between the first-price sealed-bid auction, the Dutch
declining-price auction, the English first-price ascending-bid auction or
the Vickrey second-price sealed-bid auction (ALL of this discussion so far
has dealt only with a cross-breed form of the last 2 types).

Boy, once you get me started, I do run on, don't I? <VBG>

So, back to the original question - Why do I need to know the number of
possible combinations at all?

Because, by knowing them, I can modularly code for them in such a way that,
no matter what business practice changes occur, the basic structure of my
program doesn't change. I won't have to change the part that decides which
action module to perform, I'll only have to rewrite the effected module(s).

Take the 4 variable case, with 75 possibles. I've identified 50 possibles
that shouldn't happen based on 2 basic fundamental definitions of the
application. 1 other basic application rule says that 12 of these really
have no effect on the results (but I still want to keep them), leaving me
with only 13 situations where something actually has to be done.

It also gives me an advantage in dealing with my end user - I'm very
confident that I've got a finite but complete set of possible things that
can happen in his work flow (as it relates to bidding, at least). I have
exactly 16 questions to ask, of the form of "if this, this, this and this
happen, what happens to that and that". Very specific, and any discrepancies
will be very obvious.

By doing the same thing with the 5 variable case (which has 541 possibles),
I'll have the same advantages as above, PLUS a pretty good estimating and
decision making tool. I'll know how many more action modules I'll have to
write, so I'll be able to give a pretty good guesstimate of how much the
proposed business process change will cost - a good tool for deciding if
it's worth it or not.

Done - I've gotta do some actual work now and this is getting pretty far
OT - I don't want to get any demerits.<G>

Thanks much


Mike McBee
Signature House
[email protected]
www.signaturehouse.net
304-842-3386

-> -----Original Message-----
-> From: [email protected] [mailto:[email protected]]On
-> Behalf Of MvMarkus
-> Sent: Wednesday, March 09, 2005 09:14 PM
-> To: 'Signature House'; 'Miva-Users'
-> Subject: RE: [meu] OT Programming Conundrum - But where else can I find
-> such excellent help?
->
->
-> Hi Mike,
->
-> As others indicated, I still think that you are approaching the solution
-> from the wrong direction, and after reading the instructions for your
-> auction this is even more obvious. Why do you need to know the number of
-> possible combinations at all?
->
-> An error in your reasoning may be that you are treating all your
-> constraints
-> without consideration for the chronological/logical order of the auction,
-> nor with the constraints or conditions created through the
-> interactions or
-> effects of other users (and their consequences for a bidder who
-> has a MaxBid
-> that is not yet reached and therefore should automatically augment).
->
-> On the other hand some variables only apply at the end of the
-> auction - for
-> example RESERVE. In other words, most combinations exclude each
-> other right
-> off the start, so there is absolutely no need anymore to do any further
-> computation with them, and other conditions or cases will apply
-> later or in
-> addition. Your approach may be at the same time too simple and too
-> complicated.
->
-> One way to narrow down the combinations and constraints is to design a
-> simple use-case scenario
->
->
-> You can break your auction down into 3 phases
-> 1. Start
-> 2. Upbidding
-> 3. End
->
->
-> CurrentHigh = MinBid
->
-> 1.) A new bid:
->
-> IF IncomingBid < MinBid
-> ---> Save, insult and Exit
->
-> ELSEIF IncomingBid = CurrentHigh
-> ---> Error - the system should require that a new bid is at least
-> one increment higher than the CurrentHigh.
->
-> ELSE
-> ---> go to Phase 2 (now IncomingBid=CurrentHigh)
->
->
->
->
-> 2.) IF IncomingBid > CurrentHigh
-> ---> CHECK MaxBid of all bidders that are still in the auction
->
-> WHILE IncomingBids <= MaxBid
-> ---> RAISE all.IncomingBids
-> UNTIL
-> someones.IncomingBid = allothers.MaxBid+increment *
->
-> ---> someones.IncomingBid = CurrentHigh
->
-> ELSE --> outbid
->
->
-> ( * this requires an additional rules to avoid conflicts
-> with 2 or more bidders have the same MaxBid that qualifies them for
-> CurrentHigh. For example based on the time when the bid/MaxBid
-> was initially
-> submitted)
->
->
->
-> 3.) Completion of Auction (T=0)
->
-> IF CurrentHigh < Reserve
-> ---> Lost auction, no sales --> Exit
-> ELSE
-> ---> CurrentHigh = WINNER!
->
->
->
-> So regarding your combinational problem the possible situations are:
->
-> Phase 1: A>B(Exit),A=C(Error),A>C
-> Phase 2: A<C,A=C,D<C(Exit),D=C,D>C + rule to prevent conflict
-> Phase 3: T=0,C>E(Wins),C=E(Wins),C<E(Exit)
->
-> And even they could be subgrouped further so that the logic becomes even
-> clearer.
->
-> Applying
-> A IncomingBid
-> B MinumumBid
-> C CurrentHigh
-> D MaxBid
-> E Reserve
-> T TimeLeft
->
->
-> This is of course just an example with no guarantee that it covers your
-> specific situation (nor that it is accurate & complete at all).
-> Very likely
-> that I still missed something here and there and elsewhere, but
-> I hope you
-> get the idea.
->
-> Take care,
->
-> Markus
->
->
->