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

Unfurling Dicts, Tuples, and/or Floats (Unified Risk Metric PR 2) #65

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

KethanR
Copy link

@KethanR KethanR commented Nov 6, 2024

Updated get_metrics function in scenario_gym.py

@nilsgoldbeck nilsgoldbeck requested a review from hamishs November 12, 2024 18:08
values[metric.name] = value
return values
value = (
metric.get_state()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there some extra assumptions about the keys of the nested dicts? Are they floats?

Copy link
Author

@KethanR KethanR Nov 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @hamishs! Apologies for the extremely delayed reply.

Yes, the keys of the nested dicts are assumed to be floats since the round() function acts on them. However, this does not affect the metrics developed on your end (such as EgoAvgSpeed), and simply wraps the output in a dictionary with the key "Lagging Metrics Post-Runtime".

For example, if I only call EgoAvgSpeed and EgoMaxSpeed (default implemented metrics with float output) and CollisionTimestamp (another float output) like so:
image
We get an output like this:
image

I hope this is okay and makes sense, please do let me know.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @KethanR, okay I understand. Thank you for taking the time to explain and to work on the PR however I think that this is a bit complicated for the public API which we would prefer to keep simple.

Can I suggest that you implement this as a standalone function or as part of a subclass of ScenarioGym in your codebase?

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

Successfully merging this pull request may close these issues.

2 participants