Re: Assembly Language - Mathematics WITHOUT maths coprocessor

On Tue, 11 Oct 2005 10:48:35 GMT, "Richard Cooper"
<spamandviruses@xxxxxx> wrote:
>On Tue, 11 Oct 2005 03:04:28 -0400, ¬a\/b <al@xxx> wrote:
>>> i think it is more easy than what you say
>>> for input something like this:
>>> if Lstring is the string of numbers and "a" is the number
>>> result
>>> fnum a, b;
>>> unum c;
>>> char *p1, *p2;
>>> b.sn=read(Lstring, p1);
>>
>> a=b<<(32*precision);
>>
>>> if(*p1==".") ++p1;
>>> else goto label;
>>> c=read(p1, p2);
>>
>>> if(p1==p2) {label:;
>>
>>> return a;
>>> }
>>
>>
>>> if(precision<c.len)
>>> {k=c.len-precision;
>>> c>>= 32*k;
>>> }
>>> a+=c;
>>> return a;
>>>
>>> for output, something like above, should be possible
>
>That certainly doesn't look any easier. It won't work either. (not that
>I claim to understand it, but what of it that I do understand, it won't
>work)

yes you are right

>The problem is that it's just not that simple of a conversion. For
>example, 0.69 in binary is 0.1011000010100011, however 69 in binary is
>1000101, and as you see, there's just no similarity in the bit patterns.
>
>Now if you took the binary form of 69 and divided it by 100 (decimal),
>then you'd have the correct bit pattern. However, that's basically just
>doing what I said, except that it breaks the number into two halves and
>does each seperately. I fail to see how going through all of that trouble
>is any easier than the method I outlined.
>
>>> if(precision<c.len)
>>> {k=c.len-precision;
>>> c>>= 32*k;
>>> }
>
>You particularly want to account for the cases with lots of extra decimal
>places. For example, if I were doing 32-bit numbers with 8 fractional
>bits, I'd likely be reading the number into a 64-bit integer. The integer
>part is 24 bits, so that means I have 40 bits left over that I can toss
>extra decimal places into.
>
>So say I get this number as input:
>3.1415926535897932384626433832795028841971693993751
>
>Those 40 bits can hold log_10(2^40) or 12.04119983 decimal digits. (Or if

this is false 40 bits hold [log_10(2^40)+1]=13 decimal digits
(log_10(128) = log_10(2^7)= 2.1 != 3)

>you wanted to do it the easy way, you'd just divide 40 by 3.321928095 and
>get the same number.) So what I'd do in my number reading routine is make
>it just always read 12 digits after the decimal point.

the problem is not so complex and i have found a easy "formula"
that find soon the array of a big fixed point integer
For inverse problems i use the same formula.

but there is a problem in output of numbers that has many '0's like
5.00000000012 -> 5.00000000000

and this is not a good thing for a 64 bits of fraction data
.