I’m making a model which initially could be a minute based model, but now I have to change the time frame. Is it possible to change time frame from minutes to days?
it is advised not to change the model time units once you created the model since there are a few functions that cannot be adapted (such as toTimeoutInCalendar), it is also advised to use the time units in all functions so you CAN change the time units early on, for example time(MINUTE)
with that being said, you can change it
Adding to Felipe's correct answer: there is no need ever to change the model time unit, if you use calls of time() and date() correctly:
As long as you always specify the time unit in the calls (time(SECOND) or date(YEAR)), your model will not suffer changing the time unit.
So you can "refactor" your model by specifying all such calls correctly and then, changing the model time unit is fine. It will not even have an impact on the model performance our results!
Check the help to understand these concepts, maybe easier than redoing the entire model.
PS: Even without it, there is literally no need to change the model time unit. Just adjust the run speed of the simulation experiment if it was too slow/fast
Related
I want to renew a variable if it is outdated - obviously this could be done with storing its creation time.
However - is there a (possilby undocumented) way of figuring out WHEN a variable in workspace was declared?
No, there is no way to know when a variable was created. People have explored the array metadata in detail, and nobody has found any indication of creation time stamps.
Furthermore, such a data field has no uses in general, and therefore are unlikely to be implemented, as a time stamp would just take up memory without providing a benefit.
For the very few cases where such a time stamp would be useful, I’d recommend creating a class that behaves like a normal numeric array, but additionally carries a time stamp.
The usecase
We got multiple changelogs stored in the database, and want to create a histogram monitoring the duration between changes.
The problem
There doesn't seem to be a way to set the start time of a Historgram.Timer, e.g we want to set it to lastUpdated given the current changelog.
Avenues of approach
1 Subclassing Histogram
Should work. However the java-lib use protected/package-private extensively, thus making it hard without copying large portions of the library.
2 Using reflection
After a Histogram.Timer is created it should be possible to use reflection to set the start field. The field is marked as private final, and thus a SecurityManager could stop us in some environments.
Ideas?
Neither of the solutions seems like the correct way to go, and I suspect that I'm overlooking a simpler solution (but could find anything at SO or google). We're using grafana to visualize our metrics, if thats at all helpful in this scenario.
You don't need to subclass Histogram, as you don't need to use Histogram.Timer only because your histogram is measuring times.
Simply call myHistogram.observe(System.now() - lastUpdated) every time you record a new change in the database.
In official documentation I can't find any information how to write conditional statements for java.util.Date type fact fields in guided rules. For example how to compare such field to current date, check if it is equal omitting time, or check if it is date before some time from now?
Drools isn't a real-time program and it doesn't have an innate idea of Time or Now. If you need to investigate relations of some fact property w.r.t. some point of time X, you'll have to establish a fact carrying X as its data, and write your rules based on that.
A more or less coarse approximation of a fact representing Now can be made using timers. You can implement a rule that modifies a fact containing a value representing Time (e.g. java.util.Date) every second, or less frequently.
Blending out the time of the day is something you'll have to do using Java or DRL functions. Alternatively, if it is days you are interested in, use some custom class representing days, with some suitable day 1 defined by you.
you can give like
inputDate>=11-Nov-2014
provide your current date to inputDate rule input Fact variable.
I have started using drools a week ago.
I need to calculate average of a metric over a window-duration, say 4s. Below code-snippet of Drools will do this job.
... over window:time(4s) ...
However, I want to take this value as input to a rule with the value taken from control-panel UI where someone, say the customer, can specify the window duration.
I tried many options, including the one below, but that doesn't compile.
... over window:time($SlidingWindowDuration)
Googled for hours, but there is little documentation available on this subject.
Any clues in this regard would be of great help to me.
The length of a sliding window:time cannot be set dynamically. (I think this is so because dynamic lengths would make it impossible to infer an expiration offset for the automatic removal of obsolete events.)
Note that if this length can be set by the user before the engine is started and remains constant afterwards, you can insert the duration into the rule text, compile on the fly (only the rules that need last-minute editing) and execute.
To be absolutely dynamic, you'll have to implement the "window" mechanism explicitly. Make the timestamp an attribute of the event and set it explicitly: then you can base reasoning on timestamp differences, retract old events explicitly and compute the average over all that's left using a simple accumulate CE.
When defining a model in ACT-R, I would like to set for each of my productions, a different firing time.
How could I do that?
Thanks!
Not too many ACT-R modelers here, huh?
First off, keep a copy of the ACT-R reference manual handy. This a great resource that answers 90% of the questions you will have.
You can set a production's action time using (spp <production-name> :at <time>) or you can set the default action time using (sgp :dat <time>). Times are in seconds, so the default is .05.
That being said, you should modify these parameters very rarely, if at all. The whole point of production firing time is that it's supposed to represent a psychological constant. If you're tinkering with this, your model may fit the data but is less likely to be psychologically plausible. And if you don't care about psychological plausibility, then you shouldn't be using ACT-R! But there's an exception to every rule, so proceed with caution.
While this is a bit old, this question still comes up fairly high on Google when searching for ACT-R production firing times, so I feel it is acceptable to post a response.
As a published ACT-R modeler with 4 years under my belt, I would like to echo Jeff's statements. You very, very rarely modify most ACT-R parameters for the exact reason Jeff stated. All aspects of ACT-R and the amount of time certain modules take to fire are empirically backed by many studies. If you start changing these, then your model, like Jeff said, is completely implausible. While some modelers do change these values, they have empirical data to back up their reasons for changing any parameters.