| Friday, November 12, 2004 - 02:58 pm |
The change you are requesting would tend to create lots of small contracts, rather than a few large contracts. This would be more of a strain on the servers when these contracts had to be processed each month for no real gain
If that's true, then what you say makes sense.
But I'm not sure it is true.
For example, suppose we have 4 companies supplying services, at 100 units each.
And suppose we have 12 companies demanding services, for a total demand of 480 -- 40 each. There's a 80 unit shortfall.
Now, as it's currently set up when you set up the contracts, the "first" 10 corps set up their contracts. 8 corps set up contracts with individual suppliers for 40 units each, and two more set up contracts with *two* individual suppliers for 20 units each. (Since each supplier can't give 3 40-unit contracts.)
So we've got 12 contracts covering the 400 units and supplying 10 out of the 12 requesting corps.
Now, suppose, instead, the algorhythm looks at the supply:demand ratio and sees that it's 480:400 -- or 6:5. So it says "aha -- only supply up to 83% of the request." Functionally, each of the 12 corps is demanding 33 units rather than the full 40.
When contracts are signed, each of the 4 corps supplies 33 units to 3 different requesters. For a grand total of 12 contracts, one for each consumer.
So actually it doesn't necessarily add many contracts at all -- in this example it adds none: 12 contracts of 20 or 40 units supplying 10 industries versus 12 contracts of 33 units supplying 12 industries.
While on the whole it might add a few contracts - the numbers won't always be this felicitous - I don't think you're in any danger of a large increase in the # of contracts.
One way to "fake" this *without* substantially changing the sign-contract routines would be to allow a manually-entered "cap" on contracts in the sign-contract page, just as there is currently a "cap" put on the offer-contract page.
The user, in the situation above, could manually enter "83%" and that would prevent the corps from signing contracts beyond that portion of their monthly demand.
All the algorhythm would need to do in this case would be to scale the requested-contracts accordingly... i.e. try to sign up to n% * monthly use in contracts rather than the current 100% * monthly use.