Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: "Richard Cooper" <spamandviruses@xxxxxx>
- Date: Fri, 14 Oct 2005 02:46:05 GMT
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. .
- Follow-Ups:
- References:
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: ¬a\\/b
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: Richard Cooper
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: ¬a\\/b
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: Richard Cooper
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: ¬a\\/b
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: Richard Cooper
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: ¬a\\/b
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: Richard Cooper
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: ¬a\\/b
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: ¬a\\/b
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: Richard Cooper
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- From: ¬a\\/b
- Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- Prev by Date: Re: New to asm world!
- Next by Date: Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- Previous by thread: Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- Next by thread: Re: Assembly Language - Mathematics WITHOUT maths coprocessor
- Index(es):
Relevant Pages
|