begin quoting David Brown as of Sat, Jan 12, 2008 at 02:04:46PM -0800: > On Sat, Jan 12, 2008 at 01:07:23PM -0800, SJS wrote: > > >Equivalent features would be nice as well. Something that takes > >two strings from the command line and prints out the result in an > >easy-for-a-human-to-verify way would be very desirable. > > > >Plus, we could all then time it the same way, using the same "time" > >program, giving comparable results. > > The results I gave were equivalent to that.
I want to use the same tool to approximately measure time, so that we're actually measuring the same things in the same way. > In lisp, you generally use the > lisp interpreter as your shell and give your expressions there to evaluate. That's not very user-friendly. I don't expect Java programs to be run only from bsh, or sh scripts to require that I change my login shell just to run a program. > I haven't even figured out yet how to make a standalone program (I did a > hello world), or parse arguments and such. Important things for a language to be able to do, I should think. > Lisp's time uses the same system call to get the time as time, so I would > expect the same results. I expect all sorts of things that the profiler and unit tests tell me aren't true. I don't have that warm fuzzy from the version of lisp I have available to me. :) > >A suduko solver seems like a good fit for a lispy language. :) > > I've already moved on to directory parsing and tree walking... Heh. > >Also, it seems like there's going to be a potential problem when the board > >size is > 3x3, as then you'll have items that are bigger than your power > >increment. > > Yes, that's a bug. The 10 was just for debugging, and I forgot it. Perhaps someone fluent in lisp could offer some constructive criticism. > Although there are far bigger problems with larger boards, such as utterly > rediculous amounts of memory needed. Ah. Rouge-ish behavior, eh? > For larger puzzles, a smarter algorithm is definitely needed. There are > actually fairly simple algorithms to always solve the puzzle, but they > won't necessarily have the smallest number of moves. I think they'd be harder to grok than the plain old search. What do they do, have a series of "swap" operations that leave the other tiles unmoved? -- I have come to distrust languages that are self-contained To the point where the OS compatibility is at best feigned. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
