Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: RFC: Cross-language benchmark proposal

From: carl:cybercraft at: 10-Nov-2002 18:09

On 10-Nov-02, Ed Dana wrote:
> Carl Read wrote: >> On 09-Nov-02, Ed Dana wrote: >> >> The algorithm for any program should be specified in simple >> English. It should be void of any technical references nor should >> it suggest any technical solutions. >> >> For example, the algorithm for the RandomCopy procedure I >> mentioned earlier is: >> * Specify Source Directory * Specify Target Directory or File >> >> 1 Get all the files in the Source Directory. >> 2 Choose one file randomly. >> 3 Copy it to the Target File or Directory. >> >> Stating it this way keeps it at a "logical" level and should avoid >> any "subjective" issues as the only constraints here are the >> resources being utilized. I.e. Files and directories. >> >> Okay. And I'd write that something like this, (though with a filled >> header of course), ... >> rebol [] >> dir: %test-dir/ >> file: %test-dir/random-file >> write/binary file read/binary join dir random/only read dir >> Would Joel approve though? (; > Looks like your solution is close to my solution, with only some > minor differences. > > REBOL [ > Title: "Random Copy" > File: %RandomCopy.r > Date: 28-Oct-2002 > Purpose: { > Copies a file from the source directory specified to the > target directory or file. > } > ] > RandomCopy: Func [ > {Copies one randomly chosen file owned by the source directory > to the > target file or directory. > } > ;* Specify Source Directory > SourceFile [File!] "The directory containing the files to be > copied." > > ;* Specify Target Directory or File > TargetFile [File!] "The Target directory/file to be copied to." > ] [ > ;1 Get all the files in the Source Directory. > Files: read SourceFile > ;2 Choose one file randomly. > Random/Seed Now > ;3 Copy it to the Target File or Directory. > Write TargetFile Read to-file join SourceFile Pick Files Random > Length? Files > ] >
> First, I chose to create mine as a function, for repeatable > purposes. I actually use it. :) It chooses my sig file, for example. > Second, as part of my algorithm, I had specified a Source and Target > directory. I met that specification, in part by creating it as a > function.
Your... Specify Target Directory or File was a bit ambiguious I thought, and I chose file, but I can see how Target could be either, and my attempt just assumes it's a file.
> Third, I chose to use Random/Seed to insure true randomness. At > least, it was my perception that it would be truly random. :) So, in > this context, is it any more or less random than your solution?
Yours would be better, else you'd always get the same results from startup given an unchanged directory.
> Also, you chose to Write the file as a binary file. Is this safer? > Or just focused on binary? Just wondering...
If you don't specify binary, it's possible the file could be changed...
>> ? read
USAGE: READ source /binary /string /direct /no-wait /lines /part size /with end-of-line /mode args /custom params /skip length DESCRIPTION: Reads from a file, url, or port-spec (block or object). READ is a native value. ARGUMENTS: source -- (Type: file url object block) REFINEMENTS: /binary -- Preserves contents exactly. You didn't say what type of files could be in the directory, so binary would be safer. There would need to be a fuller description of what the directory could contain I think. If just files, then no problems, but if directories too, then you'd have to say what to do with them. They could be required to be ignored, copied if they're chosen as the random choice, or looked through too if the files within them are to be part of the random choice.
> I think that this can be graded for "effort" by measuring the number > of steps in the algorithm (5) by the number of actions taken in the > solution (11). Which means it scores about 45% for completeness > (5/11), which is, actually, very good. My java solution scores much > worse: 28 actions or 18%. > Admittedly, my Java solution could probably be reduced in the number > of actions taken to meet the algorithm, but what I find interesting > about this situation is that I've known Java longer than I've known > REBOL (1997 vs. 2001) and I wrote my REBOL solution in 1/4 the time > and using considerably less code. :) > Some thoughts: > I'm using the concept of "Actions" to measure the solution against > the algorithm. I was originally thinking of using "Lines of code" to > measure the effort of the solution. I switched to actions because, > in Java for example, you can stack as many commands as you want on a > single line. > As I suggested earlier, I personally think such a web site should be > more than just a competition site. I think it should also be a "how > to" site, which is why I chose to make my solution utilitarian. You > need a means to drive people to the site and a reason for them to > stay. Once they find it useful, they'll take a closer look at the > other solutions available and see for themselves who is better and > who isn't.
-- Carl Read