<nalaginrut>yeah, receive a bug report of Artanis in the early morning #I love this life <please_help>Is there already a symbolic differentiation package for guile? <please_help>if not, is there a way to get the text represented by a variable? <please_help>(define f (+ (* 2 3))) (get-text f) ; => '(+ (* 2 3)) <nalaginrut>please_help: not for the current guile I think. But IIRC there's plan to add source code into compiled object, but I'm not sure. Maybe I recalled wrong thing... <adhoc>please_help: how do other schemes or common lisp do it ? <please_help>adhoc: I seem to recall some lisp (SBCL? Maybe Gambit?) having the ability to output the code corresponding to an object, though my memory is fuzzy on the subject <please_help>nalaginrut: wouldn't that be pretty heavy, space-wise? <please_help>guess I'll go with a fairly complete almost-compiler or something <xyh>in the master branch of guile, it seems that it is taking forever to compile "module/ice-9/psyntax-pp.scm", in which there is a 2000+ LOC letrec* ! <xyh>is it a bad coding style? or guile compiles big letrec* slow? <mark_weaver>xyh: psyntax-pp.scm is an intermediate representation of psyntax.scm. it is needed to bootstrap itself. <mark_weaver>and the reason it is compiling so slowly at this stage is because the compiler has not yet been compiled. <mark_weaver>so you're using an interpreter to interpret the compiler to compile the compiler. <mark_weaver>the compilation will be progressively faster as more of the compiler is compiled. <mark_weaver>many other compilers avoid the bootstrapping problem by simply requiring that you start with a pre-compiled binary of the compiler, e.g. sbcl and ghc. <xyh>and cumcl requires pre-compiled compiler, sbcl does not. <mark_weaver>if you start with only a C toolchain, how does one bootstrap sbcl? this is an important question, because we would like to add sbcl to GNU Guix, and would prefer to avoid starting with any additional pre-compiled binaries (besides the C toolchain and basic utilities) <mark_weaver>I guess you need to start with a CL implementation, but what are the options that actually work in practice? any free ones that can be bootstrapped from C? <mark_weaver>I confess I didn't research this question myself, but more than one person has scratched their heads on how to bootstrap sbcl and suggested that we might have to start with the binary. <nalaginrut>it's bad if a package needs a specific precompiled binaries in Guix. Maybe put it to a 'untrust' group? <mark_weaver>I'm not familiar with OpenMCL, but clisp is definitely a possibility. we already have gcl, but apparently that isn't able to bootstrap sbcl. <nalaginrut>a precompiled compiler could construct attack things while compiling compilers, and there's a loop even if we can compile the precompiler... <mark_weaver>openmcl seems to not be in debian, which is a bad sign <mark_weaver>hmm, openmcl is now called Clozure CL (CCL), and wikipedia claims that it is distributed under LGPLv2.1. I wonder why it's not in debian, and if it can be bootstrapped without pre-compiled binaries. <mark_weaver>bootstrapping CCL without pre-compiled binaries doesn't look hopeful <xyh>mark_weaver: sorry I am wrong about sbcl, maybe the saying "Radical changes have been made to some parts of the system (particularly bootstrapping)" on :: http://www.sbcl.org/history.html had gave me wrong impression on this, my fault. <xyh>mark_weaver: I switch from sbcl to ccl a while ago, for sbcl can not compile one of my macro (callede DEFTEST), sbcl will use up its heap when compiling it (and very slow), no matter how large you let the heap be. while ccl will compile all fo my code in an instant of time. <xyh>as for clisp, the development seems not active, and I can not use the Current version: 2.49 (2010-07-07) with slime well (at least not as easy as sbcl or ccl). <mark_weaver>well, even if not useful for much else, it seems that clisp is our only hope for bootstrapping sbcl from C. <nalaginrut>sounds like a recursive expand consumed the whole stack? <xyh>nalaginrut: no idea, I am not interested in sbcl anymore, when I see how fast ccl's compiler is. <mark_weaver>xyh: can CCL be bootstrapped from anything other than a binary of itself? <mark_weaver>looking at their site, I see no architecture-independent source code downloads. <mark_weaver>even the links to the subversion repo are architecture-specific. <nalaginrut>I'm not a common lisp user, but clisp looks fine, why people don't use it? <xyh>mark_weaver: I think it can not. I will try some other implementations (and maybe report to you after then) <mark_weaver>nalaginrut: yes, I should clarify that when I wrote "even if not useful for much else", I didn't mean to imply that it wasn't useful, just that I don't personally know because I haven't used it. <nalaginrut>mark_weaver: no, I think you misunderstood. I guess you're talking about bootstrap issue. But I mean people could use clisp rather than other implementation ***mario-go` is now known as mario-goulart
<please_help>is there a way to copy an entire array chunk unto a part of another array (i.e. similar to a memcpy)? <davexunit>please_help: I only see array-copy!, which copies an entire array. is your array typed? <davexunit>if so, you could get the underlying bytevector with array-contents and use bytevector-copy! <davexunit>less convenient of course, but it's easy enough to do this way. ***dsmith-w` is now known as dsmith-work
<lloda`>please_help, to copy parts of arrays into parts of arrays, you can array-copy! into a shared array. <lloda`>I don't see any reason to go through bytevectors just to copy array blocks. It's low level and risk prone. <davexunit>I like using the bytevector procedures to avoid boxing/unboxing floats when possible. <davexunit>but of course, no need to go to these lengths if performance isn't an issue. <please_help>also, is there a not-inplace version of array-map somewhere? <lloda`>davexunit, you don't need bytevectors to avoid unboxing if you operate with typed arrays. You can use the typed arrays as such with no unboxing. Maybe I misunderstand. <lloda`>please_help, there's no new-array version of array-map! or array-copy!. Not dificult to make one, though. <davexunit>lloda`: for copying arrays, that's probably true. haven't tested, but it would make sense. <davexunit>but for things that need to ref and set elements, it's slow. <davexunit>for example, I represent transformation matrices as 4x4 f32 arrays. <davexunit>and to make matrix-matrix and matrix-vector products fast, I have resorted to using CBLAS functions. <lloda`>yes, I remember. but the bytevectors? where do they enter? <lloda`>I mean beyond bytevector->pointer if you use the ffi... <davexunit>yeah, there's that, and then I also do bytevector copies for moving data to/from temporary buffers. <lloda`>you can use array-copy! for those copies... it should detect that your buffers are contiguous and do a straight memcpy. it will be marginally slower because of the checks involved. to me, if that's a problem, I'm already in C/C++. <davexunit>I might try to convert to array-copy! sometime and see how it goes. <davexunit>I have some bigger issues to deal with at the moment. <davexunit>I have a lot of optimizing to do to make rendering somewhat efficient. <lloda`>Guile's array interface is old, low-level, incomplete, etc. but needs users to improve :p <please_help>Is it possible to (list-ec (: x lst) (: y x) (/ y (reduce + 0 x))) for arrays? <please_help>(i.e. because array-ref requires 2 indices in the case of a 2D array) <davexunit>arrays are inherently imperative, so it would be very difficult to have code like that. <lloda`>I've never used the comprehensions, what does that do? <please_help>then (do-ec (: x lst) (: y x) (set! y (/ y (reduce + 0 x)))) <please_help>that would go through the lists of lists, binding X to each "higher level" list, then for each such binding it would bind y to each element of x <ijp>seems weird to use a reduce inside a comprehension <lloda`>so you divide each row by its sum? <please_help>that would divide each element by the sum of the elements in a row <ijp>there is syntax to let it before you iterate over it <ijp>don't ask me how, I moved to foof loop a few years back <ijp>it can iterate over vectors, since that's what exists in portable scheme <ijp>I never claimed otherwise <ijp>but if guile srfi 42 can handle arrays, then that would be an extension <please_help>it's in the suggested extensions in the srfi document though <please_help>so I guess my best bet is to create a new array view for the row, then operate on that? <lloda`>so Guile itself doesn't have any array reduction. <lloda`>there's an array-fold waiting in the bug report list, but it never got merged. <lloda`>wingo did a jpeg library that has a small array library with fold & unfold I think <lloda`>I have a library called guile-ploy where your list-ec looks like: <lloda`>$11 = #2((0 1 2) (3 4 5) (6 7 8) (9 10 11) (12 13 14) (15 16 17) (18 19 20) (21 22 23) (24 25 26) (27 28 29)) <lloda`>(ply / A (ply (verb (lambda (x) (over + x)) #t 1) A)) <lloda`>$13 = #2((0 1/3 2/3) (1/4 1/3 5/12) (2/7 1/3 8/21) (3/10 1/3 11/30) (4/13 1/3 14/39) (5/16 1/3 17/48) (6/19 1/3 20/57) (7/22 1/3 23/66) (8/25 1/3 26/75) (9/28 1/3 29/84)) <lloda`> (ply (verb (lambda (x) (over + x)) #t 1) A) computes the sums of the rows <lloda`>reductions are a weak point I'm afraid, I haven't thought them properly over higher rank arrays <lloda`>please_help, no problem. Reductions & the 'verb' thing are a bit of a mess but I'm happy with some of the other functions there, like (from) or (reshape), much more convenient than make-shared-array. <lloda`>problem with arrays in Guile is nobody uses them, so the interface is old & clunky. But the foundation is mostly right. <please_help>Why don't people use arrays, though? Does nobody care about using the FFI to bind high-performance libraries? <mark_weaver>please_help: srfi-42 doesn't handle arrays out of the box, but it's extensible, so it could be added easily enough. <lloda`>please_help: imo it's part cultural problem and part just lack of community. we need more users & contributors. and the ffi is relatively recent... <mark_weaver>I confess that I usually use vectors because they are portable. although my code usually won't run on other schemes without some tweaks, I try to keep those tweaks to a minimum. <mark_weaver>which is not to say that you shouldn't use arrays. absolutely, we should improve our array support, and I appreciate all of the work lloda` and wingo have done in this area. <mark_weaver>probably we should include array generators for SRFI-42 out of the box, for example. <wingo>there are lots of ways to handle arrays tho; hard to make nice abstractions :) <mark_weaver>indeed, and I realize that SRFI-42 generators probably inherently assume one-dimension only. <mark_weaver>well, I'm not sure about that, I'd have to refresh my memory <please_help>Do vectors have the nice properties of arrays such as maybe-contiguous allocation and bytevector compatibility though? <ijp>what do you mean bytevector compatibility? <ijp>you can't treat an arbitrary vector as a bytevector, that wouldn't make sense <lloda`>therefore bytevector compatibility doesn't make a lot of sense <mark_weaver>SRFI-4 uniform numeric vectors are also fairly portable, and maybe more appropriate here. <please_help>You can treat an array as a bytevector, though, which is nice <mark_weaver>and SRFI-4 uniform numeric vectors are implemented as bytevectors in guile. <lloda`>(array-contents A) -> #f, can treat it as bytevector <wingo>you can treat the backing vector of a typed array as a bytevector. not the array itself, for multidimensional arrays, and not all arrays. <lloda`>right. If the array equals it's backing bytevector, then you can treat it as... what it is <please_help>srfi-4 has the inconvenient that you need to know the type of the vector at the time you're writing the code, or design a custom dispatcher, though <please_help>it's easy enough to generate the array-type for arrays on the other hand <wingo>either way is easy enough to change :) <mark_weaver>please_help: I'm not suggesting that you avoid arrays. <mark_weaver>please_help: just trying to explain why they're not getting enough love <please_help>however, isn't it useful to consider alternatives, mark_weaver? <lloda`>that's a problem with array-map (which Guile doesn't provide) wrt array-map!, you'd need to give the type <please_help>if the type is not specified, use the same type as the provided vector, otherwise use the type provided? <mark_weaver>please_help: could be. might also be useful to try to use your experience to come up with ideas on how to improve our array support. <lloda`>mark_weaver: definitely, we need that <lloda`>please_help: problem is that the return type depends on the function. <lloda`>e.g. (array-map sqrt #f64(-1 -2)) -> type?? <lloda`>you can't just say the output type is 'f64 <please_help>isn't it OK to fail if the user does not provide the correct arguments to get the results they want? <lloda`>exactly, that's why you need to provide a place for the argument. In this case it would be <wingo>for me i use names like "typed-array-map" when i need to make an array of a different type <lloda`>(array-map 'b positive? #f64(-1 -2)) <lloda`>I do (array-map #t f arrays ...) <lloda`>typed-array-map is more like Guile does it, though <please_help>When are (typed) arrays not backed by bytevectors exactly? What is the use of this? <lloda`>typed arrays are always backed by bytevectors, but the array is a view over only part of the bytevector <please_help>Is that true also for arrays not "created" by make-shared-array/transpose/etc.? <lloda`>No. Fresh arrays are always in C-order, row-major contiguous. <lloda`>there's shared-array-root and shared-array-increments if you're curious <lloda`>(define a (array-copy #2s32((0 1 2) (3 4 5) (6 7 8) (9 10 11)))) <lloda`> #s32(0 1 2 3 4 5 6 7 8 9 10 11) <lloda`>the first row (this is using guile-ploy) <lloda`>$6 = #s32(0 1 2 3 4 5 6 7 8 9 10 11) <lloda`>(shared-array-increments (from a 0)) <lloda`>(shared-array-offset (from a 0)) <lloda`>(shared-array-offset (from a 1)) <lloda`>These are all contiguous, so (array-contents (from a 1)) <lloda`>(shared-array-increments (from a #t 0)) <lloda`>that can't be a bytevector, because of the gap <lloda`>so (array-contents (from a #t 0) #t) <lloda`>what I said before, to check that something can be used as a bytevector, you need the second arg to array-contents <mark_weaver>zacts: *nod* based on the blurb, I already know about several of the mentioned limitations. I'm sure I could learn more from the book, but I'm not sure it's the best use of my time to learn more about that right now :) <zacts>I found it to be interesting <zacts>mark_weaver: I got my book on ant colony optimization algorithms from MIT press in the mail yesterday <zacts>I may need to catch up on some of my math for it, but it doesn't look too difficult for me <zacts>it has tons and tons of summations <ArneBab>lloda`: for array-map: Couldn’t you run the function on the first element, use that to get the type, then create the array and map the rest? <lloda>ArneBab: first element is not enough, cf (array-map sqrt #f64(1 -2)) <lloda>an alternative to giving the type would be to declare the type the function, deduction will always be fragile <ArneBab>lloda`: so array-map for functions which can return different types depending on the input would have to create an intermediate datastructure with arbitrary types and check whether there’s a supertype… (slow and hard) <ArneBab>mark_weaver: I wouldn’t have been able to get to this state without your help <ArneBab>now I’ll see what the discussion brings <ArneBab>a practical side-effect is that this fulfills one requirement I still had for publishing py2guile. <ArneBab>(so that’s down to proof-reading now)