An inference step number which evenly divides the training step number causes out of bounds indexing

[colinjneville]

DDIMScheduler's first time step is effectively inference_steps * train_timesteps / inference_steps, which if there is no truncation, puts it exactly at train_timesteps, just out of bounds.

thread '<unnamed>' panicked at 'index out of bounds: the len is 1000 but the index is 1000'
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\panicking.rs:584
   1: core::panicking::panic_fmt
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\panicking.rs:142
   2: core::panicking::panic_bounds_check
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\panicking.rs:84
   3: core::slice::index::impl$2::index<f64>
             at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\slice\index.rs:250
   4: core::slice::index::impl$0::index
             at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\slice\index.rs:18
   5: alloc::vec::impl$16::index<f64,usize,alloc::alloc::Global>
             at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\alloc\src\vec\mod.rs:2628
   6: diffusers::schedulers::ddim::DDIMScheduler::step
             at diffusers-0.1.2\src\schedulers\ddim.rs:74

[siriux]

I can confirm this bug.

Also, there are many other divisions that in the python library are div_floor divisions that can potentially create similar problems.

[LaurentMazare]

I guess we can either do some rounding to help with this or at least check that the numbers are divisible and if not make a nicer error message so that the underlying issue is easier to diagnose.

[LaurentMazare]

I just pushed a very simple fix for this, feel free to re-open if you run into further issues.