class YPetri::Simulation::Recorder

A machine that receives alerts during simulation and records a recording according to its implementation. Alerts are received via #alert! method. The recording being recorded is stored in +@recording+ instance variable. This can be reset by #reset! method, which also accepts arguments to change the recorder settings and/or insert another recording.

Constants

SAMPLING_DECIMAL_PLACES

Attributes

features[R]

Public Class Methods

new(features: net.State.Features.Marking( free_pp ), recording: nil, **nn) click to toggle source

Initializes the recorder. Takes 2 arguments: :features expecting the feature set to record during simulation, and :recording, expecting the initial state of the recording.

# File lib/y_petri/simulation/recorder.rb, line 33
def initialize features: net.State.Features.Marking( free_pp ),
               recording: nil,
               **nn
  @features = net.State.Features( features )
  recording ? reset!( recording: recording ) : reset!
end

Public Instance Methods

alert!() click to toggle source

Hook to be called by simulators whenever there is a state change. The decision to sample is then the business of the recorder.

# File lib/y_petri/simulation/recorder.rb, line 60
def alert!
  sample! # vanilla recorder samples at every occasion
end
new_recording() click to toggle source

Construct a new recording based on the Recording() class.

# File lib/y_petri/simulation/recorder.rb, line 42
def new_recording
  @features.DataSet.new
end
recording() click to toggle source
# File lib/y_petri/simulation/recorder.rb, line 16
def recording
  @recording.tap { |dataset|
    dataset.instance_variable_set :@settings, simulation.settings( true )
  }
end
reset!(features: nil, recording: nil, **named_args) click to toggle source

Assigns to +@recording+ a new DataSet instance. If no arguments are supplied to this method, the new recording will stay empty. A recording can be optionally supplied via :recording named argument.

# File lib/y_petri/simulation/recorder.rb, line 50
def reset! features: nil, recording: nil, **named_args
  @features = net.State.Features( features ) if features
  @recording = new_recording
  @recording.update Hash[ recording ] if recording
  return self
end

Private Instance Methods

sample!(event) click to toggle source

Records the current state as a pair { sampling_event => system_state }.

# File lib/y_petri/simulation/recorder.rb, line 68
def sample! event
  # TODO: Method #get_features( features )  seems to be just a little bit
  # roundabout way of doing things, but not much more so than #send method,
  # so it's still somehow OK. The question is, who should know what the
  # features are and how they are extracted from various objects. Features?
  # Or those objects?
  #
  # Ruby already has one mechanism of features, which are called properties
  # of objects, and are presented by selector methods. Features reified as
  # first-class objects are themselves responsible for their functional
  # definitions. Features as first-class objects are related to Ted Nelson's
  # ZZ dimensions. Current "Features" will have to be somehow merged (or
  # at least, it will be necessary to consider their merger) with the ZZ
  # structures once YNelson is finished to the point to which it should be
  # finished.
  #
  # It seems to me that there is no use to decide in advance and in general
  # who should hold the functional definition of every feature and every
  # object. Sometimes it is convenient if the objects help to compute their
  # common features (akin to patients being able to tell the doctor their
  # name and family history), while in other cases, the features themselves
  # should define the procedures needed to extract the values from the
  # objects (akin to the doctor examining the patient).
  #
  record = simulation.get_features( features )
  recording[ event ] = record.dump( precision: SAMPLING_DECIMAL_PLACES )
end