Converting numbers in strings without using ItoA

[gabor]

Hi!

I need an algo that converts a number in any representation (like binary, tercial, decimal, hex, etc...) given in a string to another representation stored again in string without calculating the numeric value. I meet this problem when I wanted to convert REAL4/8/10/16 numbers into decimals. There, the REAL numbers are represented in binary format. Since the value of such REAL number can be huge, it is impossible to convert such a number using the regular conversion methods.
Is there a trick to convert chunks of the string into chunks of the other string? Or I have to use the regular conversion method modified with extra large integer division?
Any idea, help or link appreciated!

Greets, Gábor

[Ratch]

gabor ,

I need an algo that converts a number in any representation (like binary, tercial, decimal, hex, etc...)

     There is not single algo that will do that.  You need a program comprised of different sections that will process the different formats, while perhaps using one or more algos to perform their respective functions.

it is impossible to convert such a number using the regular conversion methods.

     No, not impossible.  If a human can do it, then so can a knowledgeable programmer.

Is there a trick to convert chunks of the string into chunks of the other string?[/

     I don't quite know what you mean?

Or I have to use the regular conversion method modified with extra large integer division?

     A little more specificity is in order for the above questions.  The "trick" involves definitive programming for the desired result.

     I think you need to write a outline of a performance specification denoting the inputs and output formats.  It will help you focus your efforts.  Ratch 

[Tedd]

General algorithm:
- convert input string to binary-value (e.g. dword), using the appropriate base (you need to know what base it's in before you interpret it)
- convert the binary-value to a string representation (in the appropriate base) to give the output string.

The problems will appear when the numbers become larger than dword, but this is easy to handle (if you do know how big they will be.)
And it will mean that you have to store the intermediate list of dwords in memory, between the first and second steps.

To do it piece-wise, I can imagine, will start to get quite complex. The main problem will be that a digit in the first string will take a different number of bits in the second string - so converting one digit at a time will mean producing (for example) either 0.2 digits of the second, or 1.8 digits of the second string (depending wether the first base is bigger or smaller than the second.)

[gabor]

Hi!

Thanks for the answers!

Ratch, I thought that I was not able to express myself very clearly, but Tedd seems to have understood what I am after.
I made some search on the net, but couldn't find any algos that wouldn't care about or predict the size of the float to be converted. Such an algo Tedd wrote is not much work to code, I calculate the numeric value stored by the input string and then convert this value into the output string. The weak point of this method is the size of the numeric value. Tedd, what did you mean with that list of dwords? Should be the input string partially converted into several dwords?

To clarify things I came up with this idea when I needed a way to display and input floats in textboxes. Well, any ideas for this will succeed to according to my current goals :) I have an algo, really simple to convert a float into decimal string with given precision, the algo uses the FPU. Would this be the best (easiest) solution?
Thanks again.

Greets, Gábor

[ChrisLeslie]

gabor

Sorry but I am a little confused. My original impression was that you wanted to convert one string representation to another without calculating numeric values, eg "F" converts to "15" by perhaps somehow manipulating ascii bytes or whatever. Maybe that is why Ratch said what he did. Isn't converting via a dword value calculating a numeric value, and using ItoA-type methods to do so?

Chris

[raymond]

the algo uses the FPU. Would this be the best (easiest) solution?

Using the Fpu is definitely the easiest solution to convert floats to ASCII. The number of significant digits in the output should be a function of the precision of the float. For example, a REAL4 only has a precision of about 7 significant digits in the decimal system. It may thus be misleading to output a number such as 321.9876543210987 when the number is no more precise than 321.9877.

Also, if the number would be in the range of 10^200 for example, you don't want to print out 200 digits in the string. You may want to use the scientific representation. The same applies to very small numbers if you want to represent the significant digits.

Raymond

[u]

I think that for the task, you have to stop thinking about dwords, fpu, and think like a human with a pencil and piece of paper. Representing the data in strings is inconvenient for the algorithms, so... use reversed strings :).

By reversed strings I mean zero-terminated strings, where bytes are digits, and the first byte is with lowest power. For instance, one-hundred fifty will be "051".


I've attached a sample proc, that converts from hex/oct/bin/dec/float to dec ("dec" is integer), has unlimited length of strings (so it can convert 300-digit numbers, for instance). With the ideas behind this proc, you can easily make the other procs (to convert to float,bin,... strings).

I.e,

Code Select Expand


main proc
local str1[100]:byte
invoke sconvToDec,addr str1,T("0x100000000000000000000000000000000000000000000000000000000c")
prints &str1
ret
main endp

VKDebug prints 431359146674410236714672241392314090778194310760649159697657763987468

[attachment deleted by admin]

[Tedd]

The weak point of this method is the size of the numeric value. Tedd, what did you mean with that list of dwords? Should be the input string partially converted into several dwords?

This only becomes an issue if you expect the input number to represent a binary value requiring over 32 bits, and so it won't fit into a dword. A simple solution to that is to represent the binary value as a 'list' of dwords (like you would use 2 dwords for a 64-bit number) - giving you as many bits as you require for the intermediate representation.
I was thinking only in terms of integers, but extension to floating-point shouldn't be difficult as long as you take the exponent into account and correct its position accordingly (it represents the nth power of the base, but each base is different.)