Skip to content
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

DiscreteUpdater does not take isterminal into account #471

Open
zsunberg opened this issue Apr 6, 2023 · 3 comments
Open

DiscreteUpdater does not take isterminal into account #471

zsunberg opened this issue Apr 6, 2023 · 3 comments
Labels
Contribution Opportunity This would be something that would be very useful to the community and a good modular addition.

Comments

@zsunberg
Copy link
Member

zsunberg commented Apr 6, 2023

Currently the DiscreteUpdater does not check for terminal states.

If isterminal and the simulator are implemented correctly, if we receive an observation, we should be able to conclude that we were not in a terminal state.

@zsunberg zsunberg added the Contribution Opportunity This would be something that would be very useful to the community and a good modular addition. label Apr 8, 2023
@dylan-asmar
Copy link
Member

This isn't an issue if the observation function is defined correctly, right?

In update(bu::DiscreteUpdater, b::DiscreteBelief, a, o), we have

for (sp, tp) in weighted_iterator(td)
    spi = stateindex(pomdp, sp)
    op = obs_weight(pomdp, s, a, sp, o) 

    bp[spi] += op * tp * b.b[si]
end

My thoughts are if we aren't expecting an observation if sp is terminal, then that should be reflected in op = obs_weight(pomdp, s, a, sp, o).

Is there a case you saw or were thinking of where this isn't the case?

@zsunberg
Copy link
Member Author

zsunberg commented Jan 9, 2024

I think solvers, belief updaters, and simulators should avoid calling obs_weight or observation when s is terminal. We should not force problem implementers to define obs_weight or observation when s is terminal since it is often not clear what observation distribution should be returned, and it will just force them to write dummy code to handle that case.

@dylan-asmar
Copy link
Member

That makes sense to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Contribution Opportunity This would be something that would be very useful to the community and a good modular addition.
Projects
None yet
Development

No branches or pull requests

2 participants