1

I have a routine that converts base10 to bas32 and what is interesting that when I double check some numbers using online conversion tools there seems to be an issue. Here are some numbers and the results of my conversion:

9990330227991015 = 8RU4S26R8F7
9990330227991016 = 8RU4S26R8F8
9990330227991017 = 8RU4S26R8F9

However, all 3 numbers using several online tools (such as http://www.unitconversion.org/numbers/base-10-to-base-32-conversion.html and http://www.kaagaard.dk/service/convert.htm) return 8RU4S26R8F8. I thought it might be the numbers length but the conversions do change if you go higher or lower.

Any ideas why this should be?

harriyott
  • 10,505
  • 10
  • 64
  • 103
Russell Weetch
  • 113
  • 1
  • 3
  • 12
  • 5
    If three different numbers in base10 convert to the same number in base 32, there's a bug in the converter. Not seeing the code for either these online tools or yours, there's little more to say. – Don Roby Jan 23 '13 at 11:39
  • 1
    Do you think **your** converter is wrong, or would you like help with debugging the javascript-baed implementation on some 3rd party site? – Cosmin Prund Jan 23 '13 at 11:47
  • If all you want is double-check your algorithm, use numbers that can be safely represented using a 32 bit signed integer: 8 digits, and if'ts 9 digits better start with a 1 as 2 is not all that safe. – Cosmin Prund Jan 23 '13 at 11:52
  • no I wasn't concerned about my algorithm just wondered as to the reason teh others were incorrect as it was also an issue in some other software at our clients. – Russell Weetch Jan 23 '13 at 14:24

2 Answers2

3

It is funny that I have just found this post as I have just investigated this issue with the exact same numbers for our software developed in Delphi as a client was receiving the below after using our conversion tool:-

9990330227991015 = 8RU4S26R8F8
9990330227991016 = 8RU4S26R8F8
9990330227991017 = 8RU4S26R8F8

The online tools you refer to are incorrect for the same reason as our tool is incorrect, basically don't use a floating point, use a 64bit integer to handle large numbers more accurately..

A fix is about to be delivered to our Client...

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Stuart
  • 31
  • 1
  • 2
    You got me curious. The basic algorithm for converting from base-to-base requires integer division and using the remainder as the next digit in the target base. How did you end up with a floating-point based algorithm? Any chance you used the `real` Delphi type? Because that's only 48 bits long, it probably can't represent the whole number, so it probably got truncated from the start. – Cosmin Prund Jan 23 '13 at 12:08
  • My application did the correct calculation - my routine uses Int64 - I was just curious that some of the online tools (and some other apps at our client - I wonder if it is the same one :-)) made the above error and thought it worth mentioning. – Russell Weetch Jan 23 '13 at 14:12
1

It seems that the general consensus is that the online tools that I looked at are probably using real numbers rather than Int64. Using floating point numbers gives the incorrect results illustrated above.

Russell Weetch
  • 113
  • 1
  • 3
  • 12