Random numbers and repeatable sequences

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Random numbers and repeatable sequences

grampajohn
Administrator
I've been looking at the powertac-random code, and I'm not quite sure how to use it, or even whether it's necessary. This code is far too heavyweight to be used to generate all random numbers, but I suppose it could be used only to provide seeds for the normal java.util.Random facility. In this case, most of the code in RandomSeedService could go away, along with the dependence on competitonId.

So here's a scenario that might make sense:

A module (perhaps a Customer model) needs a sequence of random numbers. When it starts up, it requests a long from RandomSeedService, and then uses that seed to initialize a java.util.Random instance, which it henceforth uses to generate its random values. If we need distributions other than uniform and gaussian, I have some code lying around somewhere that can produce exponential distributions and probably a few others.

The purpose of RandomSeedService is to permit re-play of a random sequence, and therefore an exact repeat of game conditions in order to compare performance of different agent configurations. In order for this to work, it's necessary that the sequence of random numbers generated by a server module be completely independent of agent behavior. So for example, if we have a customer model that uses random numbers to produce its consumption and production behaviors, we cannot write code that uses extra random values in cases where the customer is responding to a variable-rate tariff.  This can create some interesting design challenges; one way to deal with this might be to use multiple random sequences inside such a model, one for behaviors that are independent of broker actions, and another for each individual broker whose actions require the customer to generate additional random values. This problem can also create interesting testing challenges -- exactly what they are is left as an exercise for the interested reader.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|

RE: Random numbers and repeatable sequences

Wolf
Administrator

That’s an important point! Maybe we need to issue a ticket on this and a future experimental manager, since this is really important for our research setup later as well.

 

Thanks,

 

Wolf

 

From: grampajohn [via Power TAC Developers] [mailto:[hidden email]]
Sent: Sunday, March 20, 2011 04:55 PM
To: Wolf Ketter
Subject: Random numbers and repeatable sequences

 

I've been looking at the powertac-random code, and I'm not quite sure how to use it, or even whether it's necessary. This code is far too heavyweight to be used to generate all random numbers, but I suppose it could be used only to provide seeds for the normal java.util.Random facility. In this case, most of the code in RandomSeedService could go away, along with the dependence on competitonId.

So here's a scenario that might make sense:

A module (perhaps a Customer model) needs a sequence of random numbers. When it starts up, it requests a long from RandomSeedService, and then uses that seed to initialize a java.util.Random instance, which it henceforth uses to generate its random values. If we need distributions other than uniform and gaussian, I have some code lying around somewhere that can produce exponential distributions and probably a few others.

The purpose of RandomSeedService is to permit re-play of a random sequence, and therefore an exact repeat of game conditions in order to compare performance of different agent configurations. In order for this to work, it's necessary that the sequence of random numbers generated by a server module be completely independent of agent behavior. So for example, if we have a customer model that uses random numbers to produce its consumption and production behaviors, we cannot write code that uses extra random values in cases where the customer is responding to a variable-rate tariff.  This can create some interesting design challenges; one way to deal with this might be to use multiple random sequences inside such a model, one for behaviors that are independent of broker actions, and another for each individual broker whose actions require the customer to generate additional random values. This problem can also create interesting testing challenges -- exactly what they are is left as an exercise for the interested reader.

Cheers -

John


If you reply to this email, your message will be added to the discussion below:

http://power-tac-developers.975333.n3.nabble.com/Random-numbers-and-repeatable-sequences-tp2706244p2706244.html

To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.



Disclaimer
De informatie verzonden in dit e-mail bericht inclusief de bijlage(n) is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde van dit bericht. Lees verder: http://www.eur.nl/email-disclaimer.

The information in this e-mail message is confidential and may be legally privileged. Read more: http://www.eur.nl/english/email-disclaimer.

Reply | Threaded
Open this post in threaded view
|

Re: Random numbers and repeatable sequences

chris.flath
In reply to this post by grampajohn
I would say that for every server configuration in the near future there should not be broker-dependent random seeds. This is just a design paradigm that the customer models (the critical component for this issue) need to follow. This limitation is not too major and there is still enough potential for randomization.
Reply | Threaded
Open this post in threaded view
|

Re: Random numbers and repeatable sequences

grampajohn
Administrator
chris.flath wrote
I would say that for every server configuration in the near future there should not be broker-dependent random seeds. This is just a design paradigm that the customer models (the critical component for this issue) need to follow. This limitation is not too major and there is still enough potential for randomization.
The problem is not broker-dependent random seeds. The problem is random sequences that have been seeded with a known value and (might) have variable length due to interactions with brokers. I expect this to be an issue only in customer models that might behave differently under different tariff conditions.

So for example, a customer model that draws random values to drive its behavior might want to behave differently if it is facing time-of-use or variable-rate tariffs than it does facing a simple fixed-price tariff. If this different behavior requires additional draws of random values, then we have a potential divergence.

There are two ways to solve this problem: (a) Make sure we always draw the same number of random values for a given timeslot, regardless of behavior options. That might mean, for example, that you always draw all the values you might need at the beginning of a timeslot, then use what you need and discard the rest.  (b) The model could use separate random sequences (with separate seeds) for "normal" operation and for "optional" operations, but even in that case it would need to ensure that the number of draws per timeslot for each sequence is identical regardless of broker behavior (as observed through availability of tariffs).

Is this clearer?

John
Reply | Threaded
Open this post in threaded view
|

Re: Random numbers and repeatable sequences

chris.flath
grampajohn wrote
(a) Make sure we always draw the same number of random values for a given timeslot, regardless of behavior options. That might mean, for example, that you always draw all the values you might need at the beginning of a timeslot, then use what you need and discard the rest.
This is exactly how I see it - the random component in consumption should not be induced by the broker / tariff but rather it should be induced by the model's base functionality. So a customer model could by default draw x consumption random numbers per time slot (e.g. baseline consumption, avoidable weather-dependent consumption, price-dependent consumption) and use these in whatever fashion it likes to use them (e.g. combining them with current weather and tariff information). With a common initialization these consumption random numbers are stable.