Skip to content

Decide on how/when to update models: lazy vs eager updates #109

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

Open
thomashopkins32 opened this issue Mar 14, 2025 · 2 comments
Open

Decide on how/when to update models: lazy vs eager updates #109

thomashopkins32 opened this issue Mar 14, 2025 · 2 comments

Comments

@thomashopkins32
Copy link
Contributor

thomashopkins32 commented Mar 14, 2025

We should decide soon on when the agent should update its internal models.

Lazy Approach

Don't update the models until you absolutely have to. For example,

agent.dofs[0].activate()

would require the models to be updated to include the new active DOF, but the models don't get retrained yet.

m = agent.objectives[0].model  # <-- does not include the recently activated DOF

Once something like

agent.plot_objectives()

is called, then this would check for a model update and re-train if necessary.

Pros:

  • Computationally efficient - you only rebuild models when you actually need them
  • Avoids unnecessary calculations if you end up changing multiple degrees of freedom before needing predictions
  • Better suits systems where model evaluation is infrequent compared to configuration changes

Cons:

  • Could introduce latency when predictions are suddenly needed
  • More complex state management - you need to track which models need updating
  • Might lead to unexpected performance hits at prediction time

Eager Approach

Update the models as soon as the agent's internals would create an inconsistency. Using the previous example,

agent.dofs[0].activate()

would be replaced with

agent.activate(0)  # <-- or use the DOF name, or a list of DOF indices

which does

def activate(self, dof_indices_or_names):
    for i in dof_indices_or_names:
        self.dofs[i].activate()
    self.update_models()

This way, the models are consistent with the internal state of the agent.

Pros:

  • Predictions are always ready with minimal latency
  • Simpler mental model and state management - models always reflect current configuration
  • Better user experience if predictions are frequently needed
  • Potentially easier debugging since system state is more consistent

Cons:

  • Could waste computation if you make multiple configuration changes in sequence
  • Higher immediate resource usage when toggling degrees of freedom
@thomashopkins32
Copy link
Contributor Author

@NSLS-II/blop-team

@thomashopkins32
Copy link
Contributor Author

thomashopkins32 commented Mar 14, 2025

A third but more complex option would be taking the hybrid approach and update models after a time interval. Thanks claude.ai 😄

import threading

class DebouncedModelUpdater:
    def __init__(self, debounce_time=2.0):
        self.debounce_time = debounce_time
        self.timer = None
        self.update_pending = False
        self.active_dofs = set()  # Track active degrees of freedom
    
    def toggle_dof(self, dof_id):
        # Update DOF status
        if dof_id in self.active_dofs:
            self.active_dofs.remove(dof_id)
        else:
            self.active_dofs.add(dof_id)
        
        # Cancel any existing timer
        if self.timer:
            self.timer.cancel()
        
        # Set the update flag
        self.update_pending = True
        
        # Create a new timer
        self.timer = threading.Timer(self.debounce_time, self.update_models)
        self.timer.start()
    
    def update_models(self):
        if self.update_pending:
            print("Updating models with active DOFs:", self.active_dofs)
            # Your actual model update code here
            # build_gp_models(self.active_dofs)
            
            self.update_pending = False

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant