Skip to content

Collective reward observations do not always match their declared dtype #405

Description

@sylvesterkaczmarek

Reproduction

CollectiveRewardWrapper.observation_spec() advertises a scalar float64 COLLECTIVE_REWARD, but _get_timestep uses an untyped np.sum.

On main at 992db43f45ec856d5f0d8cb2936cdb4501b8fb9b, integer rewards produce an integer observation, float32 rewards produce float32, and a standard dm_env.restart produces None for the collective reward. All fail the wrapper's own observation-spec validation.

The accumulation type can also change the numerical result: [2**62, 2**62] stored as int64 sums to a negative value, and two float16 values of 65504 overflow even though their total is representable in the advertised float64 type.

Expected behavior

Accumulate the derived collective reward in its declared float64 type. With no reward on a FIRST timestep, expose a zero collective observation while preserving the underlying reward=None, discount, observations and step type.

Keep the existing float64 calculation, reward ownership and reset/step argument forwarding. This only changes the derived observation, not the individual rewards. Regression coverage should validate the complete wrapper lifecycle against its actual specifications and retain existing float64 inputs as controls.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions