BUG DESCRIPTION:----------------uint64 integers have a better relative accuracy than decimal numbers whose mantissa is encoded on only 53 bits.For all integer processing functions, uint64 (or int64 for signed values) should be the basic, a-posteriori downgraded by any required conversion into double.This is the case for dec2base() that presently accepts only doubles.It was fine when all encoded integers had a less accurate mantissa. It is no longer the case with uint64.--> dec2base(uint64(2^54+1), 2) // inappropriate error message:dec2base: Wrong type for input argument #1: A matrix of integer value expected.--> dec2base(double(uint64(2^54+1)), 2)dec2base: Wrong value for input argument #1: Must be between 0 and 2^52.ERROR LOG:----------See aboveHOW TO REPRODUCE THE BUG:-------------------------dec2base(uint64(2^54+1), 2)dec2base(double(uint64(2^54+1)), 2)OTHER INFORMATION:------------------This impedes all functions using dec2base: dec2bin, dec2oct, dec2hex, etc
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Let's feed a bit this discussion. First, let's see what close concurrents do:
Matlab yields an error
dec2base(2^54+1,3)
Error using dec2base (line 22)
First argument must be an array of integers, 0 <= D <= 2^52.
Octave silently replaces non-significant digits with zeros
n = 2^55+3;
base2dec(dec2base(n,3),3)
ans = 3.6029e+16
nn = base2dec(dec2base(n,3),3)
nn = 3.6029e+16
n==nn
ans = 0
My feeling:
a) I am not really at ease about stopping everything with an error as soon as
one too big entry is in a (possibly huge) array of all other good values.
b) I am not really at ease about returning silently some non-relevant/arbitrary information
Some suggestion
a) for dec2base(): replace all non-significant output digits with "#" instead of "0"
b) for base2dec():
- Output Nan when all clear digits are acceptable, but some low-weight ones are "#"
- When some input digits are not acceptable (wrt the input base),
either keep the error as implemented when processing the #16135 (closed) (https://codereview.scilab.org/21033)
or output Nan instead of yielding an error.