Re: Assembly Language - Mathematics WITHOUT maths coprocessor

On Fri, 14 Oct 2005 02:46:05 GMT, "Richard Cooper"
<spamandviruses@xxxxxx> wrote:
>>> 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
>
>Nope, I'm right.

no you are wrong [log_10(x)+1] where []="integer part" is how many
digits is the number x. For x=2^40 the digits are 13 =[log_10(2^40)+1]

> 2^40 = 1099511627776
1234567890123
13 digits

>10^12 = 1000000000000
>10^13 = 10000000000000
>
>So, 13 decimal digits are capable of holding more possible values than 40
>bits can hold, however, 40 bits can hold slightly more than what 12
>decimal places can hold. So I think my answer of 12.04119983 is a little
>more correct, as 40 bits can hold as many values as 12 decimal digits,
>plus just a little bit more.
>
>> (log_10(128) = log_10(2^7)= 2.1 != 3)
>
>No, 2.1 isn't 3, but the thing is you need 3 digits because 2 isn't 2.1.
>You can't fit into 2 digits that which requires 2.1 digits, and since you
>can't very use 2.1 digits, you have to use 3.
>
>(Of course, if you're making a multimeter, you can always add that 1/2
>digit, or maybe one of those 3/4 digits, but in reality they're more like
>a 3/10 digit and a 6/10 digit. But why let mathmatics get in the way of
>electronics. We've got those fun resistors numbered on a logarithmic
>scale, but some of the logarithms are a little bit off:
>
> 10 ^ (0/12) = 1.0000 -> 1.0
> 10 ^ (1/12) = 1.2115 -> 1.2
> 10 ^ (2/12) = 1.4678 -> 1.5
> 10 ^ (3/12) = 1.7783 -> 1.8
> 10 ^ (4/12) = 2.1544 -> 2.2
> 10 ^ (5/12) = 2.6102 -> 2.7 (incorrect)
> 10 ^ (6/12) = 3.1623 -> 3.3 (incorrect)
> 10 ^ (7/12) = 3.8312 -> 3.9 (incorrect)
> 10 ^ (8/12) = 4.6416 -> 4.7 (incorrect)
> 10 ^ (9/12) = 5.6234 -> 5.6
>10 ^ (10/12) = 6.8129 -> 6.8
>10 ^ (11/12) = 8.2540 -> 8.2 (incorrect)
>
>So what's the deal with 2.7, 3.3, 3.9, 4.7 and 8.2? They should clearly
>be 2.6, 3.2, 3.8, 4.6 and 8.3.)
>
>So if you want the number of digits to come out in nice integer form, you
>can use this formula:
>
> bits = -int(-log_2(10^digits))
> digits = -int(-log_10(2^bits))
>
>This formula takes advantage of the fact that the int() function always
>rounds to the next lowest integer, so that -2.1 will be integerized to
>-3. So naturally that formula won't work in Perl, since Perl's int()
>function is broken.
>
>(And that never ceases to piss me off every other time I write a Perl
>script. I'm quite used to rounding numbers with the formula int(x+0.5),
>but in Perl that only works for positive numbers, seemingly because
>someone thought that they should 'fix' the int function when they
>implemented it in Perl, never considering that maybe it works the way that
>it does for a very logical reason that they just weren't aware of. The
>reason is that, if you do it the way that Perl does, and always truncate
>towards 0, then if you take the formula int(rand*10-5) a thousand times,
>then you're going to get about 200 zeros, and 100 of each of the other
>numbers from 4 to -4. With a correctly functioning int() function, you'd
>have 100 of each of 4 to -5. The problem is that always rounding to 0
>makes it so that there's twice as many numbers that round to 0 as to any
>other number. Also, where int(rand*10+5) will give you 10 possible
>values, int(rand*10-5) only gives you 9 possible values, but
>int(rand*10-15) gives you 10 again, and that's just silly.)
>
>It's also worth noting that log_10(x) doesn't tell you how many digits are
>needed to hold the number x, but rather how many digits are needed to hold
>x integer values. So log_10(100) = 2, which means that you need 2 digits
>to hold the 100 values 0 through 99. If you want to know how many digits
>are necessary for a particular number, you should use log_10(int(x)+1)
>which will give you 2.0000 for 99.9999, and 2.0043 for 100. It also gives
>you 0.3010 for 1, and 0 for 0.
>
>(Yes, you really don't need any digits to represent a zero, because all
>this formula gives us is how many digits are needed in front of the
>decimal point, and I can represent 0.123 as .123, with no digits in front
>of the decimal place. The zero in front of the decimal place is as
>useless as the other three in 0000.123)
>
>>> 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"
>
>You should share it with us.

if i have the decimal number is string format

"-1234568788887877.0000839393948450154454454"

then integer_number=-1234568788887877

i have the fractional part of the number e.g.
s ="0.0000839393948450154454454"
if r = 839393948450154454454; like big integer
the "formula" *seems* to be this:

precision= precision_in_bits_of_fractional_part

(precision)
2 * r
Fraction_number = [-------------------------------------]
(strlen(s)-2)
10

(where [] means iteger part)
so the number for conversion is:

if( Fraction_number > Max_precision_number )
{k=len_in_bits(Max_precision) - len_in_bits(Fraction_number);
Fraction_number >>= k;
}

if (integer_number>0)
number = (integer_number<<precision) + Fraction_number
else number = (integer_number<<precision) - Fraction_number

and is very easy and seems very well

>> 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
>
>Yes, post it, I'm sure I can figure out what's wrong.

it is all ok now
.

Relevant Pages

  • Re: float bug? perl 5.8, DBI and oracle 10.2.0
    ... precision numbers in oracle, you've got 38 decimal digits to play ... and with minimal coaxing perl will handle them as ... digits from a 32 bit floating point number - I'll go out on a limb ... and hazard that one can expect 12 or so digits from a 64 bit floating ...
    (perl.dbi.users)
  • Re: Changing date field in a text file...
    ... > you understand a little more about the Perl language. ... > seeing those quotes anyway. ... Those two digits will be the day number. ... The regular expression is the contents of the first pair ...
    (comp.unix.shell)
  • Re: Changing date field in a text file...
    ... you understand a little more about the Perl language. ... But the shell "eats" quotes before sending the rest to Perl. ... Those two digits will be the day number. ... The regular expression is the contents of the first pair ...
    (comp.unix.shell)
  • Re: float bug? perl 5.8, DBI and oracle 10.2.0
    ... If you want to store high precision numbers in oracle, you've got 38 decimal digits to play with, and with minimal coaxing perl will handle them as strings at the appropriate points so that the exact values go in and come out. ... I haven't done any numerical work in 10 years or so, but I seem to recall that one can reasonably expect 6 or so decimal significant digits from a 32 bit floating point number - I'll go out on a limb and hazard that one can expect 12 or so digits from a 64 bit floating point number - at any rate I'd be very surprised to get 18 significant digits. ...
    (perl.dbi.users)
  • Re: Math
    ... int main{ ... For me it reports "segmentation fault " (well, ... fractional digits. ... You can do the same in Perl of course. ...
    (comp.lang.perl.misc)