I don't know if this is the right place for this bug report. I'm not a great programmer, but I'm trying to whip some code into shape to cite in a Math paper. It's gotta be at least as fast as C programs written on this subject 20 years ago :) This code right now running on DrScheme is a lot slower than the 20 year old C records.
All tests passed on my development machine (a PowerBook running Mac OS X). I noticed the problem on Linux after releasing beta 12. The strange thing is that the segment violation disappears when the program is run with "gdb", so I can't even figure out where it is crashing. My guess at this point is that my latest modifications of the C-interface must be causing a problem when a garbage collection occurs during a Scheme to C call. I'm looking into it.
Marc
Afficher les réponses par date
I'm not a great programmer, but [...]
My guess at this point is that my latest modifications of the C-interface must be causing a problem when a garbage collection occurs during a Scheme to C call. I'm looking into it.
Thanks, Marc! I've been having a crazy Emacs problem all morning, I wonder if anyone else ever got that. Finally I saw the problem in DrScheme, and how to fix it with some Emacs. Possibly it was caused by quack.el, but switching over to gambit.el didn't fix it.
So here's a simple file "hatA":
(define (memf p alox) (if (null? alox) #f (if (p (car alox)) alox (memf p (cdr alox)))))
(write (memf odd? '(2 8 2 3 5 4 1 2 3 4))) (write (memf odd? '(2 8 2 30 50 4 10 2 30 4)))
(banach)lambdaGambit> gsi hatA *** ERROR IN "hatA"@8.9 -- Unbound variable: memf
By looking at the file in DrScheme, I saw I have a \hat{A} character after memf. I can see the \hat{A} character in this mail buffer.
I asked someone here, and he noted that my modeline was reading "u" on the far left. The Emacs manual (`s' for "mode line") in the node "Coding Systems" says type C-h C RET, and I see I'm using "u -- mule-utf-8 (alias: utf-8)". Durn! Reading more of the manual, I see to try M-x find-file-literally, and I backspace over the 2 \hat{A} characters, and the "space" in front of it. I can see by C-s that there are only 2 such "space"s in the whole file. And now it's fine:
(banach)lambdaGambit> gsi hatA (3 5 4 1 2 3 4)#f
Whew! Anyone has a tip to stay out of this problem in the future?
I'm not a great programmer, but [...]
My guess at this point is that my latest modifications of the C-interface must be causing a problem when a garbage collection occurs during a Scheme to C call. I'm looking into it.
Thanks, Marc! I've been having a crazy Emacs problem all morning, I wonder if anyone else ever got that. Finally I saw the problem in DrScheme, and how to fix it with some Emacs. Possibly it was caused by quack.el, but switching over to gambit.el didn't fix it.
So here's a simple file "hatA":
(define (memf p alox) (if (null? alox) #f (if (p (car alox)) alox (memf p (cdr alox)))))
(write (memf odd? '(2 8 2 3 5 4 1 2 3 4))) (write (memf odd? '(2 8 2 30 50 4 10 2 30 4)))
(banach)lambdaGambit> gsi hatA *** ERROR IN "hatA"@8.9 -- Unbound variable: memf
By looking at the file in DrScheme, I saw I have a \hat{A} character after memf. I can see the \hat{A} character in this mail buffer.
I asked someone here, and he noted that my modeline was reading "u" on the far left. The Emacs manual (`s' for "mode line") in the node "Coding Systems" says type C-h C RET, and I see I'm using "u -- mule-utf-8 (alias: utf-8)". Durn! Reading more of the manual, I see to try M-x find-file-literally, and I backspace over the 2 \hat{A} characters, and the "space" in front of it. I can see by C-s that there are only 2 such "space"s in the whole file. And now it's fine:
(banach)lambdaGambit> gsi hatA (3 5 4 1 2 3 4)#f
Whew! Anyone has a tip to stay out of this problem in the future?
Marc, I figured out what caused my DrScheme/Emacs problem: pasting in from a DrScheme help window. So I have 2 suggestions:
1) Get gambit.el to alert folks to invisible garbage characters.
2) Port the DrScheme utilities in list.ss & etc.ss. Very useful functions, and I'm sure you could code up very fast versions.
How to replicate my DrScheme/Emacs fiasco:
drscheme & ;; version 208
Click "Help Desk" from Help menu
Find docs for: memf
select
PLT MzLib: Libraries Manual (memf f l) in "list.ss: List Utilities"
PLT MzLib: Libraries Manual (memf f l) in "list.ss: List Utilities"
Paste this text into an Emacs window:
(memf f l) PROCEDURE
Applies f to each element of l (from left to right) until f returns a true value for some element, in which case the tail of l starting with that element is returned. If f does not return a true value for any element of l, #f is returned.
Now I have invisible garbage characters to puzzle gsi with. I'm in trouble if I turn this garbage into a define: (define (memf f l) ...) The memf line looks like
(memf\hat{A} f l) \hat{A}\hat{A}\hat{A}\hat{A}\hat{A} PROCEDURE
when I view it with M-x find-file-literally in Emacs.
Query-replacing and C-x Esc-Esc (repeat-complex-command) tells me that \hat{A} is \302.
But it's worse than that, because there's bogus SPC's on the line that are invisible even with M-x find-file-literally. I only noticed they were there because I had a "1" in the far left mode line, which is the tipoff for coding systems. Query-replacing these \302s away leaves the top line looking like
(memf f l) PROCEDURE
But there are only 2 honest SPC's on this line. M-x find-file-literally, Query-replace and C-x Esc-Esc tell me the bogus space is \240: (query-replace "\240" " " nil nil nil)
Now I'm fine! Apologies to Neil vD: it wasn't quack.el's fault :) I suppose I shouldn't expect sympathy when I was too lazy to type (define (memf f l) ...) & pasted it in. A tipoff of the invisible garbage characters is that the words memf, f & l have different colors in the Help Desk window. Sorry for double-posting my earlier post.
Marc, I just realized that Gambit is case-sensitive by default! The Gambit manual node "Runtime options for all programs" says:
The `s' option selects standard Scheme mode. In this mode the reader is case-insensitive and keywords are not recognized. The `S' option selects Gambit Scheme mode (the reader is case-sensitive and recognizes keywords which end with a colon). By default Gambit Scheme mode is used.
I'm reading that right, aren't I? "By default Gambit ... is case-sensitive and recognizes keywords which end with a colon." I don't think you should bury information like that!!! I'd put it on the 1st page of the manual!
It's a big deal for me, because I have a lot of case-sensitive DrScheme code. I've been making the code case-insensitive, which is a pain, and fraught with peril...
Marc, I got gsc/gcc to work on my mod 2 tensor algebra program, and I'm getting the right answers. But it's not as fast as I was hoping! It's about a thousand lines of code, and it compiled just fine with
gsc drscheme Lambda-defs AdemRelationTables adem7 Curtis-alg4-1
gcc -L. -I. drscheme.c Lambda-defs.c AdemRelationTables.c adem7.c Curtis-alg4-1.c Curtis-alg4-1_.c -lgambc
and ./a.out gave me the 1180 lines of output I expected. Proving to me beyond a shadow of doubt that Gambit is really case-sensitive :)
I exported LD_LIBRARY_PATH and symlinked the library & include file:
(banach)Gambit-Curtis-alg> echo $LD_LIBRARY_PATH /rhome/richter/my-gambit/lib (banach)Gambit-Curtis-alg> ll *gamb* lrwxrwxrwx 1 richter users 41 Jan 11 21:01 gambit.h -> /rhome/richter/my-gambit/include/gambit.h lrwxrwxrwx 1 richter users 40 Jan 11 21:01 libgambc.so -> /rhome/richter/my-gambit/lib/libgambc.so
But I wonder how I can make it faster. There are 2 things I'm doing. There's a fair amount of mod 2 arithmetic to create lookup multiplication tables, but I think that gets done quickly. Then the rest is all applying these multiplication rules and sorting.
So I have "monomials" that are just lists (of length < say 100) of integers between 0 and say 100.
Then I have "polynomials" that are just lists of monomials, and these lists can get really long. Let me just give one example of what I'm doing:
We call a monomial (a b c ...) admissible if b < 2a, c < 2b,...
The monomial (0 4 12) is made admissible as the polynomial
((6 7 3) (6 5 5) (5 8 3) (5 7 4) (5 5 6) (4 7 5) (4 6 6) (3 6 7) (3 5 8))
and here's how:
0 4 12 = (3 1 + 2 2) 12
= 3 (10 3 + 9 4 + 8 5 + 6 7) + 2 (9 5 + 8 6 + 6 8)
= (6 7 + 5 8) 3 + 5 7 4 + 4 7 5 + 3 6 7
+ 6 5 5 + (5 5 + 4 6) 6 + 3 5 8
= 6 7 3 + 5 8 3 + 5 7 4 + 4 7 5 + 3 6 7 + 6 5 5 + 5 5 6 + 4 6 6 + 3 5 8
= 6 7 3 + 6 5 5 + 5 8 3 + 5 7 4 + 5 5 6 + 4 7 5 + 4 6 6 + 3 6 7 + 3 5 8
I used the multiplication rules, in order:
0 4 = 3 1 + 2 2 1 12 = 10 3 + 9 4 + 8 5 + 6 7 2 12 = 9 5 + 8 6 + 6 8 3 10 = 6 7 + 5 8 3 9 = 5 7 3 8 = 4 7 2 9 = 6 5 2 8 = 5 5 + 4 6 2 6 = 3 5
and I sorted the polynomial by left-lexicographical order. It was rather tedious to do by hand right now, but you can see I got the right answer. And my program just does boatloads of this kind of applying the multiplication rules & sorting.
Here's a note on speed. I want to compute up to t = 80, and while I've been typing this letter, I computed up to t = 47. I imagine the difficulty goes up exponentially with t. I'm hoping that it will run up to t = 60 all night. DrScheme never came close to that, even with their byte-compiler. I'm including the output up to t = 30, just so you can get an idea of my alleged exponential complexity. All the output you see is stored in vectors because I have to use this information later over & over. I imagined that the cost of vectors would pay for themselves because of the frequent lookup...