[PLUG] Re: [PJUG Javamail] Re-resolved: OT: Formula For Determining # Of Digits . . .

[Phillip Miller]

There are a couple of issues I think are kind of going unnoticed here. 

First of all, when we're talking about a random distribution of integers, 
I think we're perhaps missing an important point: integers in typical user 
programs are almost certainly NOT going to be uniformly distributed from 
-MAXINT to MAXINT; probably for typical programs using typical ranges of 
integers counting typical objects of interest to users, you'd see more of 
a "normal" (bell) probability distribution centered at zero. The larger 
the number, the less likely you'd be to see it (unless you're counting 
atoms).  For this reason, you'd probably find a series of conditionals 
that starts with small numbers to be more efficient in typical programs.

Second, I notice that the solutions using logarithms don't handle boundary 
conditions very well. Almost exactly half the numbers in the integer range 
are negative; you'd want an absolute value operation in the algorithm 
somewhere, or else you'd have runtime exceptions about half the time 
(regardless of the probability distribution). Floating point arithmetic 
solutions introduce a set of exceptional conditions that haven't really 
been accounted for in the algorithms.


-------------------------------------------------
Phil Miller
IT Specialist
IBM Global Services 
Beaverton, Oregon, USA 
ofc: (503)578-5269 voice  /  775-5269 IBM tie line
home: (503)645-4466





Jon LeVitre <jonlevitre at yahoo.com> 
Sent by: javamail-admin at pjug.org
02/18/2005 11:07 AM

To
javamail at pjug.org, plug at lists.pdxlinux.org
cc

Subject
Re: [PJUG Javamail] Re-resolved: OT: Formula For Determining # Of Digits . 
. .







--- Joe Sam Shirah <jshirah at attglobal.net> wrote:

> 
>     Hi Travis,
> 
> > But by far the *fastest* method i could think up was this one...
> 
>     My thoughts exactly.  I hadn't posted before because I was
> going to do the timing tests first, but I'm happy to take your
> word for it.  Following is my version, which should be faster
> overall, assuming a random distribution of input values.

It will depend on the distribution or your data, but if the data is
random, Travis's method will be more efficient.

Keep in mind that about 53% of random 32 bit ints are 10 digits.  Of
the remaining values 90% are 9 digits, 9% are 8 digits, .9% are 7
digits, etc. 

You don't get much leverage by checking whether a number is > 99999,
because like 99.995% are.
 
Jon


 
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 
_______________________________________________
Web Site - http://www.pjug.org/
Javamail mailing list
Javamail at pjug.org
http://www.pjug.org/mailman/listinfo/javamail