I see, thank you. I am still not sure using SRFI 151 will have any advantage for my program:
- Is there any plan to phase out SRFI 60, so that in the future my code using SRFI 60 would not work any longer? - Is SRFI 60 considered to be slow running code? - Is there something bad about how SRFI 60 is implemented for Guile? - Why would I use SRFI 151 instead of SRFI 60? What is the advantage of that, considering, that it would bring more code into my project, which I would have to manage and even get to run first? So far SRFI 60 has worked in my refactored (from using bit vectors to using integers) procedures. As long as I cannot see an advantage of using SRFI 151, I will probably stick with SRFI 60 usage. I might not have some knowledge context here. Thanks for hinting to SRFI 151 though. I did not know that there were several "treat integers as bits" libraries out there. Regards, Zelphir On 10/24/19 9:56 PM, John Cowan wrote: > See <https://github.com/scheme-requests-for-implementation/srfi-151>. > Clone it and do a little adapting. The .sld extension is a common, > but not required, convention for R7RS libraries, but the guts of it > are in the other files. > > On Thu, Oct 24, 2019 at 3:47 PM Zelphir Kaltstahl > <zelphirkaltst...@posteo.de <mailto:zelphirkaltst...@posteo.de>> wrote: > > Sorry, I am a bit clueless right now. I have the following questions: > > Where would I find srfi-151.sld? > > What is a *.sld file? (If I had to come up with a guess: "Scheme > language definition"?) > > If it is already standard Scheme code, why would I need to adapt > it for Guile? Does it need to be modified? > > > I think modifying an external library, which does not exist for > Guile yet, is a bit out of scope for my project. I also found > logand, logior and similar to be super fast. I expect that the > SRFI 60 functions are mapped to the Guile core logand and similar > internally. I ran a million times logand in approximately 1.3 > seconds. Is that slow? > > Background: I am working on a bit board implementation and my > current (working) implementation uses bit vectors, because I did > initially not get it, that I could use integers with those > bit-wise operations instead of bit vectors. I had the initial > impression, that the code ran fast, but using logand and logior > and similar, I already have an approximate 300x speedup. Not sure > whether that should still be considered slow. Here is some timing > code I used to measure a very simple case: > > ~~~~~ > (use-modules (srfi srfi-19)) > > (define-syntax time > (syntax-rules () > [(time expr expr* ...) > (begin > (define start-time (current-time time-monotonic)) > expr > expr* ... > (define end-time (current-time time-monotonic)) > (let* ([diff (time-difference end-time start-time)] > [elapsed-ns (+ (/ (time-nanosecond diff) 1e9) > (time-second diff))]) > (display (format #t "~fs~%" elapsed-ns))))])) > > > (time > (let ([int1 #b10101010] > [int2 #b01010101]) > (do ([i 1 (+ i 1)]) > ([> i 1000000]) > (logand int1 int2)))) > ~~~~~ > > And here is the one for my old / current code: > > ~~~~~ > (use-modules (srfi srfi-19)) > > (define-syntax time > (syntax-rules () > [(time expr expr* ...) > (begin > (define start-time (current-time time-monotonic)) > expr > expr* ... > (define end-time (current-time time-monotonic)) > (let* ([diff (time-difference end-time start-time)] > [elapsed-ns (+ (/ (time-nanosecond diff) 1e9) > (time-second diff))]) > (display (format #t "~fs~%" elapsed-ns))))])) > > > (define (binary-bit-vector-operation bv1 bv2 proc) > (define (iter bit-list1 bit-list2) > (cond [(or (null? bit-list1) (null? bit-list2)) '()] > [else (cons (proc (car bit-list1) > (car bit-list2)) > (iter (cdr bit-list1) > (cdr bit-list2)))])) > (list->bitvector > (iter (bitvector->list bv1) > (bitvector->list bv2)))) > > > (time > (let ([bv1 #*10101010] > [bv2 #*01010101]) > (do ([i 1 (+ i 1)]) > ([> i 1000000]) > (binary-bit-vector-operation > bv1 > bv2 > (lambda (b1 b2) > (and b1 b2)))))) > ~~~~~ > > It is also in my todo file on: > > https://notabug.org/ZelphirKaltstahl/bitboard/src/dev/todo.org > > (Btw.: I really like that notabug renders Emacs Org-mode files!) > > Regards, > > Zelphir > > On 10/24/19 8:50 PM, John Cowan wrote: >> Compile it yourself! Just look at the logic in srfi-151.sld and >> see how it needs to be modified for Guile. Easy-peasy. >> >> It's a lot less work to port a SRFI implementation than to do >> things from scratch. >> >> On Thu, Oct 24, 2019 at 2:26 PM Zelphir Kaltstahl >> <zelphirkaltst...@posteo.de <mailto:zelphirkaltst...@posteo.de>> >> wrote: >> >> Ah, but SRFI 151 is not implemented in my version of Guile: >> >> ~~~~~ >> scheme@(guile-user)> (use-modules (srfi srfi-151)) >> While compiling expression: >> no code for module (srfi srfi-151) >> scheme@(guile-user)> >> ~~~~~ >> >> Guile version: 2.2.6 from Guix: >> >> ~~~~~ >> guile (GNU Guile) 2.2.6 >> Copyright (C) 2019 Free Software Foundation, Inc. >> >> License LGPLv3+: GNU LGPL 3 or later >> <http://gnu.org/licenses/lgpl.html> >> <http://gnu.org/licenses/lgpl.html>. >> This is free software: you are free to change and >> redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> ~~~~~ >> >> Are you suggesting, that I copy the code for SRFI 151 from >> somewhere and put it into my project? >> >> Regards, >> >> Zelphir >> >> On 10/24/19 7:02 PM, John Cowan wrote: >>> For bitwise integers, I recommend SRFI 151. If you use your >>> implementation to provide the seven core functions >>> bitwise-not, bitwise-and, bitwise-ior, bitwise-xor, >>> arithmetic-shift, integer-length, and bit-count, all of >>> which have definitions in bitwise-core.scm that are very >>> slow, then you'll have a package that can do pretty much >>> what all the bitwise SRFIs provide and more with acceptable >>> performance. >>> >>> There is a conversion table at the end of the SRFI between >>> the names used by other SRFIs and the names used by SRFI >>> 151; they are as close to SRFI 33 and SRFI 60 as practical. >>> It is part of the Tangerine Edition of R7RS-large. >>> >>> On Thu, Oct 24, 2019 at 12:43 PM Nala Ginrut >>> <nalagin...@gmail.com <mailto:nalagin...@gmail.com>> wrote: >>> >>> Personally, I prefer srfi. But sometimes I mix with RnRS. >>> I think it's better to avoid Guile specific things, >>> however, Guile provides >>> many good things that the standard doesn't have. >>> >>> On Thu, Oct 24, 2019 at 11:56 PM Zelphir Kaltstahl < >>> zelphirkaltst...@posteo.de >>> <mailto:zelphirkaltst...@posteo.de>> wrote: >>> >>> > Hello Guile Users! >>> > >>> > I have a question regarding usage of SRFIs in Guile code. >>> > >>> > Sometimes there are core functions, which are also >>> available from an >>> > SRFI implementation. One example I am currently >>> dealing with are bitwise >>> > operations for integer numbers. There is SRFI 60 and >>> there are the core >>> > functions like logand, logior and so on. >>> > >>> > Usually I tend to think, that using the SRFI >>> implementation in such >>> > situation is better, as it is an implementation of a >>> common interface, >>> > which other Schemes might also have implemented. Using >>> that makes code >>> > more portable to other Schemes. However, I want to be >>> sure, that this is >>> > a good way of thinking about it. Are there ever >>> arguments against using >>> > an SRFI implementation, when an SRFI implementation >>> provides what I need? >>> > >>> > Another example are structs. I usually use SRFI 9 to >>> make some structs, >>> > instead of the core record or struct type. >>> > >>> > What do you think? >>> > >>> > Best regards, >>> > >>> > Zelphir >>> > >>> > >>> > >>>
