Re: Assembly Language - Mathematics WITHOUT maths coprocessor



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.

 2^40 =  1099511627776
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.

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. .



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)