Base conversion error in matlab code

Question

I created the following simple matlab functions to convert a number from an arbitrary base to decimal and back

this is the first one

function decNum = base2decimal(vec, base)

decNum = vec(1);
for d = 1:1:length(vec)-1
    decNum = decNum*base + vec(d+1);     
end 

and here is the other one

function baseNum = decimal2base(num, base, Vlen)
ii = 1;
if num == 0
    baseNum = 0;
end
while num ~= 0 
    baseNum(ii) = mod(num, base);
    num = floor(num./base);
    ii = ii+1;
end
baseNum = fliplr(baseNum);

if Vlen>(length(baseNum))
    baseNum = [zeros(1,(Vlen)-(length(baseNum))) baseNum ];
end

Due to the fact that there are limitations to how big a number can be these functions can't successfully convert vary big vectors, but while testing them I noticed the following bug

Let's use the following testing function

num = 201;

pCount = 7
x=base2decimal(repmat(num-1, 1, pCount), num)
repmat(num-1, 1, pCount)
y=decimal2base(x, num, 1)
isequal(repmat(num-1, 1, pCount),y) 

A supposed vector with seven (7) digits in base201 works fine, but the same vector with base200 does not return the expected result even though it is smaller and theoretically should be converted successfully.

Answer 1

(One preliminary comment: calling base2decimal won't result in a decimal number but rather in a number :-D)

This is due floating-point limited precision (in our case, double). To test it, just type at the MATLAB Command Window:

>> 200^7 - 1 == 200^7

ans = 

     1

>> mod(200^7 - 1, 200)

ans =

     0

which means that the value of your number in base 200 (which is precisely 200⁷−1) is represented exactly as 200⁷, and the "true" value of representation is 200⁷.

On the other hand:

>> 201^7 - 1 == 201^7

ans =

 1

so still the two numbers are represented the same, but

>> mod(201^7 - 1, 201)

ans =

   200

which means that the two values share the "true" representation of 201⁷−1, which, by accident, is the value that you expected.

TL;DR

When stored in a double, 200⁷−1 is inaccurately represented as 200⁷, while 201⁷−1 is accurately represented.

"Bigger numbers are less accurately represented than smaller numbers" is a misconception: if it was true, there would be no big numbers that could be exactly represented.

Answer 2

Judging from your own observations:

1. The code works fine in most cases
2. The code can give small errors for large numbers

The suspect is apparent:

Rounding issues seem to give you headaces here. This is also illustrated by @RTL in the comments.

---

The first question should now be: 1. Do you need perfect accuracy for such large numbers? Or is it ok if it is off by a relatively small amount sometimes?

If that is answered with a yes, I would recommend you to try a different storage format. The simple solution would be to use big integers:

uint64

The alternative would be to make your own storage format. This is required if you need even bigger numbers. I think you can cover a huge range with a cell array and some tricks, but of course it is going to be hard to combine those numbers afterwards without losing the accuracy that you worked so hard for.