Convert input number(s) (cell array of character arrays) in base 10 to base x (2 through 16). Output should be a cell of character arrays. Compute output to a maximum of 50 decimal places.
For example: Convert 1376.5 base 10 into base 2.
answer: {'10101100000.1'}
Solution Stats
Problem Comments
9 Comments
Solution Comments
Show comments
Loading...
Problem Recent Solvers4
Suggested Problems
-
16205 Solvers
-
Find the numeric mean of the prime numbers in a matrix.
9157 Solvers
-
Sum the entries of each column of a matrix which satisfy a logical condition.
176 Solvers
-
Put Two 1D matrices into one 1D matrix
142 Solvers
-
565 Solvers
More from this Author63
Problem Tags
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
The exact solution for 38.59 in base 15 is the repeating decimal 28.8cb3b3b3b3b3b3b3..., which means the given solution 28.8cb3b3b3b3b42d4a contains some "junk digits" at the end; it's not really fair to ask for those junk digits as opposed to any others. Also, it looks like trailing zeros are supposed to be removed, but some of the base 2 solutions contain a trailing zero.
Tim,
You are correct. Thanks for the comment. Fixed the errors you detected as well as a few others. Should be good now.
Hi David, nice problem but there are still I believe a few precision issues remaining in the testsuite. For example the number "7285.4" as a float can only be precisely encoded up to ~1e-12 (since eps(7285.4)=9.0949e-13), so its base-15 representation cannot be defined with 16-decimal places (as that would require >1e-19 precision). I believe perhaps you could fix that simply entering the input decimal numbers using chars, which would avoid any limited-precision issues? (or by relaxing the requirements to fewer decimal places)
Changed and fixed the problem. Input is now cell array of character arrays.
It seems the precision issues were indeed fixed. :)
Not sure what the problem was, but I changed #6 and added some additional test problems.
Oh, the problem was with my algorithm, sorry. I am indeed using python's long int (for multiplication of large integers), but I was relying on str2num for some operations (which apparently introduced floats back in my code). After removing it, it worked out fine.
PS: This new update knocked out some wrong solutions (including some of mine). Awesome. :)
In each of test3, test4 and test5, there is a number with a decimal fractional part 0.0962. It appears as thought it was converted in each case as though the fractional part was 0.962.
Corrected tests 3,4,5. Answers should all be good now.