Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re^2: Prime Number Finder

by blokhead (Monsignor)
on Nov 11, 2005 at 13:46 UTC ( #507713=note: print w/replies, xml ) Need Help??

in reply to Re: Prime Number Finder
in thread Prime Number Finder

Nice succinct algorithm, but I must take issue with
There's an interesting O(1) algorithm
You do have to execute the algorithm on a classical computer, so Q::S or not, it's most definitely not O(1). It'll be exponential (in the number of bits in $n) because behind the scenes, Q::S is dividing $n by all possible factors (what else could it be doing?). But even on a quantum computer, you still need either a division or gcd circuit (and probably a lot of other stuff), which will take some polynomial time in the number of bits.

Just because it's a one-liner doesn't make it O(1). Anyway, my favorite cutesy inefficient primality checker is

sub is_prime { ("1" x $_[0]) !~ /^(11+)\1+$/ }


Replies are listed 'Best First'.
Re^3: Prime Number Finder
by Roy Johnson (Monsignor) on Nov 11, 2005 at 21:47 UTC
    some polynomial time in the number of bits.
    If the number of bits is constant, then any polynomial time based on it is constant.

    Caution: Contents may have been coded under pressure.
      If the number of bits is constant, then any polynomial time based on it is constant.
      Big-O statements (like an algorithm taking constant or O(1) time) are statements about asymptotic behavior, i.e, how the function behaves in the limit (usually, as input size tends to infinity). If you don't look at them in the limit, then big-O-ish language (like constant time) is meaningless.

      How meaningless? Even undecidable languages have a constant time "algorithm" if you consider the input size to be held to a constant. So without viewing things in the limit, all problems become computationally equivalent in the asymptotic language.

      Update: added citation from parent node


        You're right, blokhead. I came to conclusions too fast after reading Q::S documentation. I think the documentation is badly formulated about this point, too.

        Thanks for correcting.
        It is reasonable to assume that some inputs will vary from 1 to very large. I do not agree with you that it is reasonable to assume that input numbers will in this case. There will be some interesting size of number, and not much variation around it.

        Caution: Contents may have been coded under pressure.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://507713]
[Corion]: erix: Yes, but that's mostly for skipping characters you'll never read, but this approach skips the problem of needing to load more data while looking at a half-match
[Corion]: I mostly wonder how I can add this "reversal" to my toolchest, and if it's worth it or just clever
[choroba]: It should greatly simplify the parsing code, no flags or additional reading of the next buffer needed
[Corion]: choroba: Yeah, that's why I like that approach; it seems even quite obvious in retrospect to me, but many things are in hindsight ;)

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (13)
As of 2016-12-06 15:36 GMT
Find Nodes?
    Voting Booth?
    On a regular basis, I'm most likely to spy upon:

    Results (109 votes). Check out past polls.