Anybody willing to decipher Forth program
in [Lisp]
|
From: Raymond Toy on 16 Mar 2010 22:04 On 3/16/10 5:59 PM, Hugh Aguilar wrote: > LC53 is just a toy program; nobody who knows anything about encryption > would use the linear-congruential system. I did think of one use for > LC53 though. This would be a text-editor that is designed specifically > for women to write their diaries, and in which they use LC53 > encryption to prevent their boyfriends from reading the text. Assuming > that no women are computer programmers (true as far as I know), they > will never find out how easy it is to crack the LC53. I may write this Oh, come on! Of course there are computer programmers who are women. I know some myself. And just because they're not programmers doesn't mean they wouldn't be able to crack LC53. There are quite a few women mathematicians too. Ray
From: Rob Warnock on 16 Mar 2010 22:53 Tim Bradshaw <tfb(a)tfeb.org> wrote: +--------------- | joswig(a)corporate-world.lisp.de said: | > relative packages and logical packages | | No, I want more than that: I want it to be the case that I can have | packages which will be garbage collected when all the references to | them are gone. I want a version of MAKE-PACKAGE which does not put | the package in a registry. +--------------- Uh... Hold on a second... The following pattern is *very* common: (make-package "FOO" ...) ...some other stuff... (in-package "FOO") What happens if "FOO" gets GC'd during the "other stuff"?!?!? -Rob ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Slobodan Blazeski on 17 Mar 2010 02:19 On Mar 16, 9:33 pm, Eli Barzilay <e...(a)barzilay.org> wrote: > Slobodan Blazeski <slobodan.blaze...(a)gmail.com> writes: > > On Mar 14, 8:34 pm, Eli Barzilay <e...(a)barzilay.org> wrote: > >> Slobodan Blazeski <slobodan.blaze...(a)gmail.com> writes: > >> > On Mar 13, 11:27 pm, 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. > >> > Eli I've tried your code and it takes forever 8min 36 sec to run on my > >> > Machine(*). I've run the file from DrScheme IDE with both Dr Scheme > >> > 4.15 that was in the ubuntu repositories and now I've downloaded and > >> > installed 4.24 Linux - Fedora 7 (x86_64). The result is same over > > >> By default, DrScheme runs code in "debug mode", which means that it > >> inserts lots of code instrumentation bits into the code, and that will > >> make it run much faster. Usually the difference is neglegible, but of > >> course it is much more noticeable in code like this. To turn > >> debugging off, hit the "show details" and disable all debugging on the > >> top part. But even with this there is additional overhead for running > >> in DrScheme -- I see a runtime of 35 seconds. Running the code > >> directly in mzscheme should make sure that you don't get any of these > >> costs. > > >> Another strange thing is that your junk output looks very different > >> from my junk output... I've changed the code a bit (you can get it > >> from the same URL) to always use the "abc...xyz" string and print the > >> contents in ASCII-friendly form -- this is the output that I see: > > >> #"abcdefghijklmnopqrstuvwxyz" > > >> SAMPLE is encrypted and seed is zeroed; commencing cracking...cpu time: 19292 real time: 19295 gc time: 320 > > >> The seed is: 174187923 > >> The file is: > >> #"<B!q\25z\1oP\vDJgm\17I]m\vUXwD\31\34@" > > Thanks > > > bobi(a)deus:~$ /home/bobi/lisp/plt/bin/mzscheme eli.scm > > #"abcdefghijklmnopqrstuvwxyz" > > > SAMPLE is encrypted and seed is zeroed; commencing cracking...cpu > > time: 33540 real time: 33596 gc time: 670 > > > The seed is: 174187923 > > The file is: > > #"<B!q\25z\1oP\vDJgm\17I]m\vUXwD\31\34@" > > OK, so you have 33 seconds instead of 19 seconds. I'm not sure what > would lead to such a difference (machine specs below), but it's not > the 8.5 minutes that would indicate something very wrong. I believe its my hardware spec. I'm glad PLT is fast in this toy test , will give it a more serious test afterward when I port my the program to it. Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz L2 Cache 1MiB System Memory 2GiB Mobility Radeon HD 2400 > > [The machine I'm using has two dual core Intel Xeon 5160 3GHz cpus, it > was pretty fast when we got it ~2 years ago, and I assumed (perhaps > falsly) that it's a representative of an average machine these days. > Also, it has 4gb of ram, and the OS is Fedora 7 (it's the build > machine for the x86_64 installer on our site).] > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life!
From: Nicolas Neuss on 17 Mar 2010 05:26 Slobodan Blazeski <slobodan.blazeski(a)gmail.com> writes: > SAMPLE is encrypted and seed is zeroed; commencing cracking...cpu > time: 33540 real time: 33596 gc time: 670 > > The seed is: 174187923 > The file is: > #"<B!q\25z\1oP\vDJgm\17I]m\vUXwD\31\34@" OK, so we have 33 seconds on your machine for mzscheme versus 22 seconds for SBCL. IMO, this is a very reasonable result considering that it was obtained without any type declarations. Eli, do you maybe know if this result carries over to low-level code involving uniform arrays of floating point numbers (e.g. for something like my usual floating-point performance test which I append below)? Nicolas ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;; mflop.lisp ;;;; (C) Nicolas Neuss (neuss(a)kit.edu) ;;;; mflop.lisp is in the public domain. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (in-package :cl-user) (defconstant +N-long+ #x080000) ; should not fit in secondary cache (defconstant +N-short+ #x0100) ; should fit in primary cache (defparameter *mflop-delta* 1.0 "Time interval in seconds over which we measure performance.") (defun make-double-float-array (size &optional (initial 0.0d0)) (make-array size :element-type 'double-float :initial-element initial)) (defun ddot (x y n) (declare (type fixnum n) (type (simple-array double-float (*)) x y)) (declare (optimize (safety 0) (space 0) (debug 0) (speed 3))) (loop for i of-type fixnum from 0 below n summing (* (aref x i) (aref y i)) of-type double-float)) (defun daxpy (x y n) (declare (type fixnum n) (type (simple-array double-float (*)) x y)) (declare (optimize (safety 0) (space 0) (debug 0) (speed 3))) (loop with s of-type double-float = 0.3d0 for i of-type fixnum from 0 below n do (setf (aref y i) (+ (aref y i) (* s (aref x i)))))) (defun test (fn name size) (let ((x (make-double-float-array size)) (y (make-double-float-array size))) (format t "~A-~A: ~$ MFLOPS~%" name (if (= size +N-long+) "long" "short") (loop with after = 0 for before = (get-internal-run-time) then after and count = 1 then (* count 2) do (loop repeat count do (funcall fn x y size)) (setq after (get-internal-run-time)) (when (> (/ (- after before) internal-time-units-per-second) *mflop-delta*) (return (/ (* 2 size count internal-time-units-per-second) (* 1e6 (- after before))))))))) (progn (test #'ddot 'ddot +N-long+) (test #'ddot 'ddot +N-short+) (test #'daxpy 'daxpy +N-long+) (test #'daxpy 'daxpy +N-short+))
From: Tim Bradshaw on 17 Mar 2010 07:20
On 2010-03-17 02:53:36 +0000, Rob Warnock said: > Uh... Hold on a second... The following pattern is *very* common: > > (make-package "FOO" ...) > ...some other stuff... > (in-package "FOO") > > What happens if "FOO" gets GC'd during the "other stuff"?!?!? It can't, because what I am thinking of is (assuming (make-package nil ....) makes an "uninterned" package, which it does not do in CL, it makes a package whose name is "NIL"): (let ((p (make-package nil))) ...package not eligible for GC here... (let ((*package* p)) ...or here...)) ....can be GCd here perhaps... Note, I have not thought this through in detail and in particular I am not ure this deals with the name-capture issues that people worry about (there's no doubt it's a hacky solution if it is one, but CL is about hacky solutions). |