The 5-digit number, 16807 = 7^5, is also a fifth power. Similarly, the 9-digit number, 134217728 = 8^9, is a ninth power.

How many n-digit positive integers exist which are also an nth power?

I love this sort of problem.  The algorithm for a brute force solution should be quite obvious: loop over bases and exponents, do the exponentiation, and see how many results' lengths match the exponent in question.  But the question is what the loop constraints are.  For this particular problem you can just write the loops, have them spit out answers, and then hit CTRL-C to terminate when the search stops finding results.  But that's cheating.

Once you get the constraints, writing the code is trivial.  What I couldn't figure out is how to compute the answer without the loops, though it seemed like that would be possible.  After getting the right answer with the scan/check method I read down the forum thread and someone had done it.  The proper loop constraints get you about 50% of the way, and I'd gotten another 30% of the way there, but couldn't quite get all the way.  I still have trouble applying logarithms correctly when stuff gets complicated.

Why build a custom harness?  Well, I originally considered using JUnit (or whatever) as a simple runner, but since there isn't anything to test, it didn't feel right.  It also doesn't provide a good way to get timing information for the runs.  And since I was originally using strictly Groovy, I didn't want to impose any more "ceremony" than I needed to.  I've since started doing some problems in Java simply for the performance (as well as converting some of those "secret" routines), and have generalized my harness.

First, here are the file templates for Groovy:

import util.Runner

new Runner() {
  // put some code here, eh?
}

and for Java:

import util.Runner;
import util.java.Solver;

public class BruteForce {
  public static void main(String[] args) {
    new Runner(new Solver() {
      public Object solve() {
        // put some code here, eh?
        return null;
      }
    });
  }
}

As expected the Java version requires quite a bit more ceremony, even though the semantics of the two templates are identical.  The Solver interface (used for Java) is as follows:

package util.java;

public interface Solver {
   public Object solve();
}

Finally, the Runner class, which is implemented in Groovy.  As you can see from the templates, it accepts either a Solver instance or a Groovy closure, and treats the two in exactly the same way, excepting that it picks between Solver.solve() and Closure.call() based on the type.

package util

import util.java.Solver

class Runner {

  private static ThreadLocal timer = new InheritableThreadLocal()
  private static int timerCount = 0

  def Runner(solver) {
    this(true, solver)
  }

  def Runner(doIt, solver) {
    if (! doIt) {
      return
    }
    startTimer()
    // this will send an update every five or so seconds
    volatile def updateThread
    updateThread = Thread.startDaemon {
      while (true) {
        Thread.sleep(5000)
        if (updateThread == null) {
          break // after the sleep, before the log
        }
        log("still executing...")
      }
    }
    try {
      log("starting...")
      def result;
      if (solver instanceof Solver) {    // the closure/Solver switch
        result = solver.solve()          //  |
      } else { // better be a Closure    //  |
        result = solver.call()           //  |
      }                                  //  V
      stopTimer()
      if (result instanceof String) {
        try {
          result = new BigInteger(result)
        } catch (e) {
          // oh well
        }
      }
      if (result instanceof Integer || result instanceof Long || result instanceof BigInteger) {
        log("result: $result")
      } else {
        def s = "" + result
        if (s.length() > 100) {
          s = s[0..<97] + "..."
        }
        log("result was not numeric: $s", System.err)
      }
    } finally {
      updateThread = null
    }
  }

  def elapsed() {
    get().elapsed
  }

  def formatElapsed(e) {
    def seconds = e.intdiv(1000)
    def millis = e % 1000
    def s = ""
    if (seconds >= 60) {
      s += seconds.intdiv(60) + ":"
      seconds = seconds % 60
    }
    if (s.length() > 0 && seconds < 10) {
      s += "0$seconds"
    } else {
      s += seconds
    }
    if (millis < 10) {
      s += ".00$millis"
    } else if (millis < 100) {
      s += ".0$millis"
    } else {
      s += ".$millis"
    }
    s
  }

  def log(Object msg, out=System.out) {
    def t = get()
    out.println "[${t.index}: ${formatElapsed(t.elapsed)}] $msg"
  }

  private startTimer() {
    Runner.timer.set(new TimerData(++timerCount))
  }

  private stopTimer() {
    get().stop()
  }

  private get() {
    def t = Runner.timer.get()
    if (! t) {
      throw new IllegalStateException("No timer has been started...")
    }
    t
  }
}

class TimerData {
  def index
  def startDate
  def stopDate

  def TimerData(threadIndex) {
    index = threadIndex
    startDate = new Date()
  }

  def stop() {
    stopDate = new Date()
  }

  def getElapsed() {
    if (running) {
      return new Date().time - startDate.time
    } else {
      return stopDate.time - startDate.time
    }
  }

  boolean isRunning() {
    stopDate == null
  }
}

There's a lot of stuff going on there, but primarily it's setting up a timing framework, a background thread to tell you it's still running every 5 seconds, and doing some magic with the returned solution.  As you can see, the constructor takes an optional first parameter for whether to execute.  Useful if you have multiple Runners in a single script/class, but only want to run some of them. https://maxinternet.biz/best-gas-grills-under-300

It wasn't my intent, but building this out was quite educational in the way the Java/Groovy interplay works.  Write Groovy for whatever you can, and write Java for the bits that need it.  As you can see from the templates, Java requires a lot more work, but it has benefits.  I was quite pleased to be able to use my Groovy harness (which leverages all kinds of Groovy goodness) for my Java solutions.  I originally figured I'd have to port it to Java to use it with both languages, but not the case.

As you probably expect, I was working on Project Euler.  Problem 39, to be specific.  The algorithm is simple, and if you pay attention, you don't even have to do the full scan to get the answer.  However, I couldn't get within the minute boundary with my algorithm.  I did a whole bunch of optimizations to ensure I was doing absolutely as little work as possible (including stopping the search at the known answer!) and still couldn't even come close to the minute deadline.

On a whim, I took my brutish, unoptimized version (because the syntax was less Groovy-ish) and dropped it into a Java class.  I had to add a pile of semicolons and variable types, insert a couple imports, and convert a GString, but the rest was untouched.  Full scan (from 1-1000) in 172 milliseconds.  Needless to say I was disappointed.

Am I going to abandon Groovy for Java?  Hell no.  But definitely going to consider reimplementing some of my hard-core subroutines in Java.  Just another case of knowing your tools so you can pick the right one for the job.  And just to be clear, I have no expectation that this sort of performance difference is in any way indicative of Groovy's general performance.  In fact, I find Groovy to be ridiculously fast, in general, because I'm typically doing far higher-level operations (like using Hibernate).

One interesting point was that copy and pasting the Java version into a Groovy file and running it (with all the semicolons and explicit variable typings) didn't affect the Groovy performance much.  That surprised me.  Apparently the Groovy compiler treats 'int' as 'Integer' or something similar.  I've never looked into it very deeply, but worth mentioning I thought.

Also interesting is that CFSCRIPT on CF 8.0.1 turns in times that are slightly faster than Groovy running through CFGroovy on the same page.  I would have expected the reverse since CF uses java.lang.Double internally, but it seems the lack of unboxing/reboxing makes up for the floating point calculations.

The first version just showed my stats (it had my tokens hard coded).  The current version has the ability to create a dashboard for any user via the new link at the bottom of the page.  You have to supply either your credentials or your browser cookies so the server can get your data, but there isn't any server-side storage of anything.  The URL token that identifies the dashboard as yours also carries the tokens needed to fetch data from Project Euler.  If needed, they're extracted at runtime and used.

Whether anyone will ever use it, who knows, but it was an interesting set of problems to deal with.  Also be good to clean up the URLs a bit, but didn't figure it was worth it at this point.

def factor(BigInteger num) {
  def factors = []
  while (num % 2 == 0) {
    factors.push(2)
    num = (BigInteger)(num / 2)
  }
  BigInteger end = floor(sqrt(num))
  for (def currFactor = 3; num > 1 && currFactor <= end; currFactor += 2) {
    if (num % currFactor == 0) {
      while (num % currFactor == 0) {
        factors.push(currFactor)
        num = (BigInteger)(num /currFactor)
      }
      end = (BigInteger) floor(sqrt(num))
    }
  }
  if (num != 1 || factors.size() == 0) {
    factors.push(num)
  }
  factors
}

The algorithm is pretty simple: loop through all odd numbers and see if they're a factor of the target number.  There's a special case at the top for two (the only even prime), which then lets the loop skip all the even numbers (effectively cutting it's work in half).  There's also a special case at the bottom for ones.  If you attempt to factor one or a prime number, you'll get that number back as the only item in the list, otherwise you'll get only prime factors (and no, one is not prime).  Note that the list can contain duplicates; the method returns all prime factors, not just distinct ones.

Why does this work?  Because by the time the loop gets to each number all of it's factors have been processed, so it can't be both a factor of the target number and composite (non-prime).  So if it's a factor, it has to be prime as well.

For those of you who follow me on Twitter (@barneyb), this is not the crappy algorithm I first implemented.  This is the good one.  My first attempt was an "inversion" of the sieve algorithm which resulted in huge amounts of unneeded work and memory consumption because of the data structures involved.  The second algorithm is virtually identical, just the data structures are different (enormously simpler).  I wasn't really that far off with the first attempt, I just didn't do a good job of distilling the problem down to it's essence, so I was doing a lot of extra work (three-orders-of-magnitude extra).

For example, problem 1 can be solved by a simple loop/modulo algorithm, but that gets expensive as the range increases in size (it's O(n)).  For <1,000 it's quite speedy, but for <1,000,000 it takes a long time.  There is a far better algorithm using a series expansion/summation that operates O(1).  The writeup includes discussion of both algorithms, including code.  Very cool.

If you want to find me out, I'm 'barneyb'.