Anybody willing to decipher Forth program
in [Lisp]
|
From: Nicolas Neuss on 13 Mar 2010 16:20 Hugh Aguilar <hughaguilar96(a)yahoo.com> writes: > [...] Factor is a fat language --- you are expected to learn the > vocabulary and use already-provided solutions rather than do things > your own way. My tendency to just write code and ignore the > documentation resulted in my getting criticism for being unidiomatic > --- this is at least part of the reason why I chilled out on > Factor. By switching to Common Lisp though, I might be jumping out of > the frying pan and into the fire! :-) PLT Scheme seems to be a > purposefully thin language though, so that might be more Forth-like. Scheme, surely. PLT Scheme - I doubt it. Nicolas
From: Helmut Eller on 13 Mar 2010 17:04 * Hugh Aguilar [2010-03-13 21:31+0100] writes: > On Mar 12, 6:33 pm, Helmut Eller <eller.hel...(a)gmail.com> wrote: >> The text was "abcdefghijklmnopqrstuvwxyz". > > This file is too short. There may be more than one key value that > encrypts the file identically, and there is no guarantee that LC53 > will find the same key value that was originally used; LC53 just stops > on the first key value that decrypts the entire file in sync with the > known plaintext (the high bit of each byte should be zero). So long as > LC53 does find the correct value (123456789) though, then the > benchmarking information should be correct. Use the function TEST-HOW- > FAR to find out the minimum size needed for the file. The benchmarking information is just as correct even if we don't find the correct seed. It's only important that all programs search in the same way and find the same (wrong) solution. > It is a good idea to count how many visits there are to <FIND-SEED> > and make sure that this value is the same (464723587) as what I got > with my Forth program. It is possible to get the correct answer, but > to still have a bug. This was messing me up on my assembly language > version because I had the less-than coded as a greater-than. Bugs like > this aren't normally going to happen in a high-level language, but a > little verification never hurts. Another possibility would be to write the generated random numbers to a trace file and compare the files. >> Factor 0.92 : 110 seconds fromhttp://paste.factorcode.org/paste?id=998 > > This Factor time is way better than what I had found previously (9-min > 14-sec on my laptop). Did you run your benchmark on a 64-bit machine? No, it's a 32 bit machine. > That might speed up the PRNG bottle-neck significantly. Another > possibility is that Slava improved the compiler so that it would > handle mixed-precision integer arithmetic more efficiently. He told me > that he was going to do this, so maybe he did. Good for him! > > The program posted on factorcode is pretty much the same program that > I wrote. The big difference is that Slava is using a different method > for escaping out of <FIND-SEED> than I was using. I don't even know > what CALLCCL is; that must be a new feature in the language since the > time when I was working with Factor. Or maybe it existed then and I > just didn't know about it. There are a lot of aspects of Factor that I > don't know about! > > My method of escaping out of <FIND-SEED>, which is also used in the > Forth program, is actually supposed to be for error-handling. I'm > using it for success-handling, which has raised some eyebrows. I don't > know of any other way to do this in Forth. In Factor, apparently, they > do have more than one way to escape out of a recursive function. > >> After looking at the Factor version I also recognized that haw-far could >> have been written more elegantly with POSITION-IF. > > One of my big problems with learning Factor was that I never learned > Factor's extensive vocabulary. I was always writing code that worked, > but which everybody complained was unidiomatic. Using a language in an idiomatic way seems pretty important to me. It certainly a good habit to read other peoples code especially the code written by wizards. > I am used to Forth, > which is a purposely thin language --- you are expected to write > everything yourself (even very basic things like arrays and record). > Factor is a fat language --- you are expected to learn the vocabulary > and use already-provided solutions rather than do things your own way. > My tendency to just write code and ignore the documentation resulted > in my getting criticism for being unidiomatic --- this is at least > part of the reason why I chilled out on Factor. By switching to Common > Lisp though, I might be jumping out of the frying pan and into the > fire! :-) PLT Scheme seems to be a purposefully thin language though, > so that might be more Forth-like. Scheme (before R6RS) may have been a small language but PLT Scheme is not a thin language. It's more like a zoo of languages; it's a platform for language research and teaching. >> But yeah, that even Gforth seems out of reach is a bit embarrassing. > > I always considered GForth to be a toy compiler because it is written > in C. It does generate remarkably fast code though, so maybe I should > take it more seriously. I have only recently begun using it at all. I > have found it to be about two or three times slower than SwiftForth. > By most accounts, SwiftForth is two or three times slower than VFX or > iForth, but I've never used either of those compilers, so I can't say > according to my own experience. Speed is not the only quality measure. Overall Gforth is quite a good system and it's very standard compliant. It's also the only one that comes with a decent Emacs mode. Helmut
From: Eli Barzilay on 13 Mar 2010 17:27 Hugh Aguilar <hughaguilar96(a)yahoo.com> writes: > On Mar 12, 6:33 pm, Helmut Eller <eller.hel...(a)gmail.com> wrote: >> The text was "abcdefghijklmnopqrstuvwxyz". > > This file is too short. (FWIW, I tried to have a quick and naive translation of the CL code to PLT, and on a 64 bit machine with that input file it takes about 19 seconds. But I'm not posting any code since I know nothing about it or what it should produces... (What I got was some random text which looked like the output on a different post but also had a bunch of junk characters.)) > [...] By switching to Common Lisp though, I might be jumping out of > the frying pan and into the fire! :-) PLT Scheme seems to be a > purposefully thin language though, so that might be more Forth-like. As other said, PLT Scheme is far from being a small language -- it's overall much bigger than CL (and probably on the same scale of any "real" language, including actual CL implementations). But the organization of code *and* language into separate modules tend to make it easier to learn. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
From: Eli Barzilay on 13 Mar 2010 17:29 Helmut Eller <eller.helmut(a)gmail.com> writes: > Scheme (before R6RS) may have been a small language [...] The R6RS language is also very small -- it just has more libraries. > but PLT Scheme is not a thin language. It's more like a zoo of > languages; it's a platform for language research and teaching. ....and work. PLT is most definitely not intended only for academic uses. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!
From: joswig on 13 Mar 2010 17:45
On 13 Mrz., 23:27, Eli Barzilay <e...(a)barzilay.org> wrote: > Hugh Aguilar <hughaguila...(a)yahoo.com> writes: > > On Mar 12, 6:33 pm, Helmut Eller <eller.hel...(a)gmail.com> wrote: > >> The text was "abcdefghijklmnopqrstuvwxyz". > > > This file is too short. > > (FWIW, I tried to have a quick and naive translation of the CL code to > PLT, and on a 64 bit machine with that input file it takes about 19 > seconds. But I'm not posting any code since I know nothing about it > or what it should produces... (What I got was some random text which > looked like the output on a different post but also had a bunch of > junk characters.)) > > > [...] By switching to Common Lisp though, I might be jumping out of > > the frying pan and into the fire! :-) PLT Scheme seems to be a > > purposefully thin language though, so that might be more Forth-like. > > As other said, PLT Scheme is far from being a small language -- it's > overall much bigger than CL (and probably on the same scale of any > "real" language, including actual CL implementations). But the > organization of code *and* language into separate modules tend to make > it easier to learn. Than what? Common Lisp code is organized around separate packages and systems. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! |