New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preference adjustment has been updated to include the managers of both #1122
base: main
Are you sure you want to change the base?
Conversation
moving this to 1.4 as there will likely need to be more discussion |
I'm hoping for this to go into 1.4 if CEP25 is accepted by then, FYI |
@gidden - looks like this could use a rebase. |
requesters and bidders. This will let institution and region interactions be based either trader entity. Only bidders now have no influence on the preference adjustment process, which could be updated in the future if needed. There is a notable deprecation of the *Agent* AdjustPrefs API. As was true previously, only *managers* of trading agents are called through this API, i.e., institutions and regions in the RIF model. The new AdjustPref API includes the request, bid, preference, and whether the agent is a manager of the requester or bidder (called TradeSense). Each trade has its preference adjusted individually. Anything more complex will require much more difficult logic in the DRE *and* in the agent API.
done On Tue, Sep 8, 2015 at 4:49 PM, mbmcgarry notifications@github.com wrote:
Matthew Gidden, Ph.D. |
This new API for adjusting preferences prevents traders/agents from being able to see all bids/reqs before setting any preferences. They have to set preferences based on only knowing a single bid at a time - seems like not what we want. This also is a breaking change even if it doesn't break API - any preference adjustment implemented by traders/archetypes will become completely inoperative since we no longer call the Adjust[Matl/Prod]Prefs functions anymore of anything other than the initial trader itself. This break is arguably not too problematic because we don't have any extra-kernel non-self-trader (i.e. insts, regions) that set prefs, but it is something we should consider carefully. |
I'm happy to discuss design changes. This was a first-cut and was done On Tue, Sep 8, 2015 at 9:02 PM, Robert Carlsen notifications@github.com
Matthew Gidden, Ph.D. |
@rwcarlsen, what if the ExchangeContext (i.e., all information about the current exchange) was added to the function signature? |
Something like that sounds like a fine enough solution. |
And to the API semantic breakage, do we know of any archetypes, inventory policies, etc. created by anyone that would break due to the removed calls to adjustmatlprefs? |
I know of no such archetypes/policies/etc. |
I use AdjustMatlPrefs in both my Sink and Enrichment Facility in my RandomSink branch. I didn’t realize this was going to be deprecated - perhaps we can discuss how I can modify my archetypes? -Meghan On Sep 24, 2015, at 12:02 PM, Robert Carlsen <notifications@github.commailto:notifications@github.com> wrote: And to the API semantic breakage, do we know of any archetypes, inventory policies, etc. created by anyone that would break due to the removed calls to adjustmatlprefs? — |
@mbmcgarry - do those archetypes use inventory policies? On Thu, Sep 24, 2015 at 2:44 PM, mbmcgarry notifications@github.com wrote:
|
Nope, they do not use inventory policies. On Sep 24, 2015, at 3:03 PM, Robert Carlsen <notifications@github.commailto:notifications@github.com> wrote: @mbmcgarry - do those archetypes use inventory policies? On Thu, Sep 24, 2015 at 2:44 PM, mbmcgarry <notifications@github.commailto:notifications@github.com> wrote:
— Meghan McGarry, PhD ~ http://mbmcgarry.github.io/ |
I looked in your random_sink branch and didn't see a call to Separately, if you are simply doing a check on the the request or bid, it On Thu, Sep 24, 2015 at 2:44 PM, mbmcgarry notifications@github.com wrote:
Matthew Gidden, Ph.D. |
It’s actually used in the branch random_sink1.3. Here are some links to where I call AdjustMatlPrefs: enrichment.cchttp://enrichment.cc Line 127https://github.com/mbmcgarry/cycamore/blob/random_sink1.3/src/enrichment.cc Thanks, On Sep 24, 2015, at 3:51 PM, Matthew Gidden <notifications@github.commailto:notifications@github.com> wrote: I looked in your random_sink branch and didn't see a call to Separately, if you are simply doing a check on the the request or bid, it On Thu, Sep 24, 2015 at 2:44 PM, mbmcgarry <notifications@github.commailto:notifications@github.com> wrote:
Matthew Gidden, Ph.D. — Meghan McGarry, PhD ~ http://mbmcgarry.github.io/ |
Seems pretty straightforward:
On Thu, Sep 24, 2015 at 5:06 PM, mbmcgarry notifications@github.com wrote:
Matthew Gidden, Ph.D. |
API has been updated |
requesters and bidders. This will let institution and region
interactions be based either trader entity. Only bidders now have no
influence on the preference adjustment process, which could be updated
in the future if needed.
There is a notable deprecation of the Agent AdjustPrefs API. As was
true previously, only managers of trading agents are called through
this API, i.e., institutions and regions in the RIF model. The new
AdjustPref API includes the request, bid, preference, and whether the
agent is a manager of the requester or bidder (called
TradeSense). Each trade has its preference adjusted
individually. Anything more complex will require much more difficult
logic in the DRE and in the agent API.
related to cyclus/cyclus.github.com#130 for requester/bidder preference adjustment