Convert to different bases
Style

These are in order of me thinking of them; not in order of first appearance. Sorry!

#[test]

If you mark your tests with #[test], then running cargo test will run them. If you also mark them with #[cfg(test)], then they'll only be compiled in test mode.

Unneeded collect()

cargo clippy is an invaluable tool. Here, it found an optimisation!

if !number.iter().filter(|&amp;x| *x &gt; 0 &amp;&amp; *x &gt;= from_base ).collect::&lt;Vec&lt;_&gt;&gt;().is_empty(){
    return Err(Error::InvalidDigit(from_base));
}


It points out that .collect::&lt;Vec&lt;_&gt;&gt;().is_empty() should be replaced with .next().is_none():

if !number
    .iter()
    .filter(|&amp;x| *x &gt; 0 &amp;&amp; *x &gt;= from_base)
    .next()
    .is_none()
{
    return Err(Error::InvalidDigit(from_base));
}


The compiler's probably smart enough to turn this into efficient code,[citation needed] but this code can be made clearer:

if number.iter().any(|&amp;x| x &gt; 0 &amp;&amp; x &gt;= from_base) {
    return Err(Error::InvalidDigit(from_base));
}


Unnecessary casting

inter = inter as f64/base as f64;


can be

inter /=  base as f64;


and you can get rid of all of the base as f64 bits by putting

let base = base as f64;


at the top of convert_back.

After a quick pass through cargo fmt to clean up the errant spacing and expand the iterator chain to separate lines, this all looks pretty good.

Algorithm

Your algorithm is, sadly, more limited than it looks. Your use of as is a little risky, as casting to a smaller integer truncates it. However, that won't get to be a problem, because as soon as the from_base.pow ends up with a number bigger than u32 can store, it'll panic.

You need some kind of "too big" Error variant if you want to handle this gracefully; you could check whether number.len() &gt; u32::MAX (otherwise as's truncation could cause issues), and then check whether all the .pow calls are guaranteed to work (perhaps with .checked_pow?), and then whether adding all the digits together will exceed the bounds of u32.

Alternatively, you could make the algorithm convert via base 2³² instead of u32s, which would resolve the issue.