Fix bug in normalize to avoid divide by zero

[ruijie-he]

What this does

Fixes #211. Normalize class could have a divide by 0 problem, e.g. when some of the states or actions have a fixed value.

How it was tested

Tested after extending push T / Diffusion policy to a real robot and fixing the non-XY states / actions.

---

This change is 

[Cadene]

@alexander-soare I am wondering what we should do in this context where max == min and std == 0 for certain dimensions of state and action?

For max == min, we could set the value to 1 * sign(value) to set to the arbitrary max or min or to set to 0 if the value is 0.

For std == 0, we could also set the value to 1 * sign(value) or to set to 0 if the value is 0.
We could maybe choose a higher value, but I am not sure. See:

>>> torch.randn(9999999).max()
tensor(4.9761)
>>> torch.randn(99999999).max()
tensor(5.4906)
>>> torch.randn(999999999).max()
tensor(5.7675)

We might want to add some warnings during push_dataset_to_hub but also at the begining of training, when the max - min or std are really small.

[Cadene]

Thanks for the PR, but I am not sure we want this. It could result in a silent failure.
It think we should address the issue in another way. See my other comment.

[alexander-soare]

@Cadene agreed on the warnings. I'm not totally sure on your proposed handling strategy though, unless you can confirm you've seen it done that way in other places. I'd rather stick to a more conventional method like adding 1e-8 to the denominator. It also does the job but it may cause less confusion to others trying to understand our code or port it into their own projects. Is there some reason your proposed method makes more sense?

Edit: Also I noticed that prior to this pr we have std + 1e-8. Are you suggesting we change that?

[Cadene]

@Cadene agreed on the warnings. I'm not totally sure on your proposed handling strategy though, unless you can confirm you've seen it done that way in other places. I'd rather stick to a more conventional method like adding 1e-8 to the denominator. It also does the job but it may cause less confusion to others trying to understand our code or port it into their own projects. Is there some reason your proposed method makes more sense?

Edit: Also I noticed that prior to this pr we have std + 1e-8. Are you suggesting we change that?

@alexander-soare Let's merge this PR. In a future PR we need to add a warning if one or more dimensions are detected constant at the end of compute_stats. And we should add the same warning at the start of training if these stats are used. I will take care of it.