00:01:48 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Ping timeout: 245 seconds] 00:05:16 saint_cypher [~rjspotter@70-36-245-104.dsl.static.sonic.net] has joined #scheme 00:33:04 -!- wuj [~wuj@pool-74-108-204-117.nycmny.east.verizon.net] has quit [Ping timeout: 265 seconds] 00:50:05 pchrist [~spirit@gentoo/developer/pchrist] has joined #scheme 00:50:37 -!- Axsuul [~someone@97-93-99-133.static.mtpk.ca.charter.com] has quit [Ping timeout: 250 seconds] 00:55:36 acarrico [~acarrico@pppoe-68-142-40-104.gmavt.net] has joined #scheme 00:56:09 Axsuul [~someone@97-93-99-133.static.mtpk.ca.charter.com] has joined #scheme 01:00:36 -!- saint_cypher [~rjspotter@70-36-245-104.dsl.static.sonic.net] has quit [Quit: Leaving.] 01:09:23 -!- TheRealPygo [~pygospa@217.191.169.68] has quit [Ping timeout: 255 seconds] 01:09:31 githogori [~githogori@adsl-66-123-22-146.dsl.snfc21.pacbell.net] has joined #scheme 01:11:18 pygospa [~pygospa@217.191.166.221] has joined #scheme 01:12:35 laurus [~laurus@c-68-40-207-109.hsd1.mi.comcast.net] has joined #scheme 01:12:47 In Emacs, I am running Guile Scheme through "M-x run-scheme". When I run eval-last-sexp, it doesn't print the code I am running in the *scheme* buffer. Is this normal behavior? 01:14:34 -!- masm [~masm@bl19-144-108.dsl.telepac.pt] has quit [Ping timeout: 252 seconds] 01:14:40 eval-last-sexp is alwyas evaluating the previous sexp as emacs lisp code, in emacs. 01:15:02 If you want to get the result inserted in the current buffer, you can use the prefix: C-u M-x eval-last-sexp RET 01:15:12 pjb, I don't think so: I see Scheme mode as the major mode when I am in .scm files 01:15:34 It does not matter, eval-last-sexp is always the same old emacs lisp function evaluating emacs lisp code. 01:15:40 Perhaps you're doing C-x C-e ? 01:15:59 Key bindings may change, and this one may invoke a different command in different modes. 01:16:04 pjb, oh, you're right, I'm sorry! 01:16:06 I am running scheme-send-last-sexp 01:16:18 Good. 01:16:30 But I still don't see the code showing up in *scheme* 01:17:17 Now, it would be hard for me to answer precisely, because I don't use bare inferior-lisp. I wrote my own sexp evaluation forms, to have them behave like eval-last-sexp (with and without prefix), between any lisp (or scheme) buffer and the inferior-list. 01:17:45 I see :) 01:18:28 What do you mean by "showing up"? The code itself isn't supposed to move into the Scheme buffer, only the results of evaluation should be displayed 01:18:28 I would just prefer to see the Lisp code being entered into the *scheme* buffer, it's weird to see those prompts like that without anything between them 01:18:40 franki^, right, I'd like to see the code itself as well 01:18:54 Why? That seems odd to me. :s 01:18:57 pjb pasted "my C-x C-e in lisp and scheme buffers with inferior-lisp" at http://paste.lisp.org/display/116185 01:19:13 _danb_ [~user@124-149-55-13.dyn.iinet.net.au] has joined #scheme 01:20:34 slime is even worse, it doesn't show anything in the *slime-repl* buffer if you C-x C-e in a source buffer... 01:20:34 01:20:36 pjb, ah, that's neat. But what is lisp-eval-region? 01:20:59 It is in inf-lisp.el, part of inferior-lisp. 01:21:54 Oh, inferior-lisp 01:21:56 I was using "run-scheme" 01:22:16 No wonder your function wasn't working for me :) 01:22:46 But run-scheme uses inferior-lisp, no? 01:22:55 pjb, I don't think so, actually 01:23:25 Correct, it uses directly comint. 01:23:43 Well, I have no experience with run-scheme. I always used inferior-lisp even for scheme. 01:23:56 pjb, yeah, I think inferior-lisp is better... I was using it for Clojure for a while 01:25:13 I forgot how to start it up though 01:25:20 M-x inferior-lisp RET 01:25:51 But then again, I have a few personnal commands to launch it, with options to make new instances, select various implementations, etc. 01:26:09 Could someone help me to enumerate the leaves of a binary tree? http://paste.lisp.org/display/116186 01:26:27 I've been failing horribly all day, and am now feeling quite pathetic :\ 01:26:31 That's the curse of knowing and liking to program in lisp including emacs lisp, you get to customize emacs beyond sharability. 01:27:49 pjb, yeah... I was about to say something to that effect. :P 01:27:52 franki^: when you consider a tree you have basically two kinds of nodes: inner nodes (including root), and leaves. So your functions will have two parts. 01:28:31 In the case of a leaf, it will have to increment the counter and return the leaf number. 01:28:52 In the case of an inner node, it will have to enumerate the children, and keeping track of the counter. 01:28:56 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 01:29:07 In addition, for the root it will have to set an initial counter value. 01:29:22 franki^: now, it would be nice if you showed us your code so far. 01:31:03 I pasted half of a solution here yesterday, I was just looking for the link. But it was terrible. 01:31:18 I don't think I can find it though, because I "annotated" over it, or soemthing.. 01:31:30 But, it looked a bit like this: http://paste.lisp.org/display/116160#1 01:31:55 pjb, even running your lisp-eval-last-sexp doesn't seem to print out the sexp in the *inferior-lisp* buffer 01:31:59 Then Riastradh gave me some advice that I didn't understand, so I got even more confused and went to bed. 01:32:03 Heh 01:33:12 Then today I've tried several other methods, including passing different versions of the tree as arguments, so that I can try to "jump" back up to previous nodes and stuff. But I just got hideously confused 01:33:22 Sigh. 01:33:28 First, you need some abstraction. Don't use directly car, cdr, etc. but define functions to access the label, left and right children. 01:33:56 (define (my-car x) (car x)) 01:33:59 If you want to make a functional version, you could return two values, the new subtree, and the new counter. 01:34:04 jonrafkind: no! 01:34:07 wrong!! 01:34:13 I did actually do that (as a previous exercise in this book asked) but removed them for the post, to make it more "neutral" 01:34:14 (define (node-label node) (car node)) 01:34:33 ugh, lists as adhoc datastructures.. use records/structs if you have them 01:34:49 jonrafkind: it does not matter once you've introduced the functional abstraction. 01:34:54 pjb: I would like a functional version, if I'm capable of understanding it. :) 01:34:55 -!- githogori [~githogori@adsl-66-123-22-146.dsl.snfc21.pacbell.net] has quit [Remote host closed the connection] 01:35:24 So, let's (define (number-leaves tree) (number-leaves-with-counter tree 0)) 01:35:40 Okay, with you so far. :) 01:35:46 and we'll implement (number-leaves-with-counter tree counter) --> (new-tree new-counter) 01:35:59 So actually, (define (number-leaves tree) (first (number-leaves-with-counter tree 0))) 01:36:23 -!- bgs100 [~ian@unaffiliated/bgs100] has quit [Quit: leaving] 01:36:25 If tree is the empty tree, what should number-leaves-with-counter return? 01:36:38 '()? 01:36:42 and? 01:36:46 0? 01:36:53 No. The old counter. 01:37:05 Ah, true. 01:37:24 Sorry, I was imagining only an empty tree 01:37:40 So we'll have (define (number-leaves-with-counter (tree counter) (cond ((tree-empty? tree) (list tree counter)) ...)) 01:37:55 Now if it's a leaf, what should be returned? 01:39:19 Umm, the counter (tthat indicates the number of the leaf) and the counter plus one (to continue counting from)? 01:39:24 Yes. 01:39:44 So we'll have as second clause: ((tree-leaf? tree) (list counter (+ 1 counter))) 01:40:03 and finally, if it's an interior node, it's a little more complex, what should we do? 01:40:14 githogori [~githogori@adsl-66-123-22-146.dsl.snfc21.pacbell.net] has joined #scheme 01:41:23 I would naturally say "recursively call the function on each child node" (If that's the right terminology), but that won't result in the correct counter... 01:41:41 So, do I need to call one and then use it's return value to pass as the counter for the other? 01:41:44 Or something.. 01:41:52 s/it's/its/ 01:42:06 Indeed when you call recursively on the first child, you need to collect the result, keep the first as the new child, and the second as the new counter to be passed to the second recursive call. 01:42:26 You may use two let embedded. 01:42:47 Hmm 01:43:14 pjb, thanks for your help! Have a good night :) 01:43:22 Good night! 01:43:31 -!- laurus [~laurus@c-68-40-207-109.hsd1.mi.comcast.net] has quit [Quit: Leaving] 01:43:35 franki^: let's do the first recursive call, on the left child. 01:44:18 -!- jonrafkind [~jon@crystalis.cs.utah.edu] has quit [Ping timeout: 272 seconds] 01:46:34 pjb: What jonrafkind said was very relevant -- when you define a `node-label' as you did, you can still (easily) trip with using it over values that are not supposed to be lists, and you can still (easily) trip with using list functions on things that are supposed to be nodes. 01:46:45 Yes, indeed. 01:46:47 xwl_ [~user@nat/nokia/x-ueybckbfpufejhma] has joined #scheme 01:46:49 With a proper struct (= a new type), neither of these is a problem. 01:47:19 It depends whether you want to have a 'typed' approach or if you can do with an 'untyped' approach. 01:47:28 In fact, IIRC, Matthias had worked with a student that showed that using lambdas all the way as a type representation is something that can never work. 01:47:37 (His first student, I think.) 01:47:39 Nonetheless, the point of a functional abstraction is that it allows you to change the representation. 01:47:58 I'd be interested in seeing that proof... 01:48:21 That's not saying much when the barriers are things that you need to enforce only in your mind... 01:48:29 I believe you can construct a typed language with pure lambda calculusl. 01:48:31 (The functional abstraction point.) 01:48:45 Ohoooo.... 01:48:57 That's actually something that I just got to in my class: 01:49:09 I give the students a language that is "almost like scheme except..." 01:49:20 ...it's automatically curried, 01:49:31 ...you can't have recursive definitions with `define', 01:49:46 -!- Quadrescence [~Quad@unaffiliated/quadrescence] has quit [Ping timeout: 252 seconds] 01:49:48 ...you don't have *any* built-in functionality except for `lambda' and function applications, 01:50:03 ...and by that I mean *any* -- you don't even have numbers and booleans, 01:50:05 For a simple reason: Church numerals. So like on any von-neuman computer you can implement typed language over arrays of integers, in pure lambda calculus you can also encode typed values. 01:50:11 ...and it's a lazy language. 01:50:37 Exactly -- the point in all of this is that you *can* certainly make up your world by encoding values as functions, 01:50:53 but the bottom line is that in a system like that there is one very big problem: 01:51:02 *All* values are one-argument functions -- always. 01:51:03 Yes, some values are alien. 01:51:19 And because of this you have absolutely no chance of ever getting any error. 01:52:01 There are no alien values inside the language -- there's only one back-door to translating encodings to scheme values, which is allowed only inside `test' forms. 01:52:22 It takes a while to realize that in this language there cannot be any errors -- ever. 01:52:42 Well, except for an occasional non-termination, but that's not a real error. 01:53:15 So the conclusion is that you cannot -- in this language -- have a proper encoding that provides you with the usual abstraction barriers that forbid you to add a number and a list and get some result. 01:53:24 It's like...the Library of Babel! 01:53:28 :-) 01:53:37 The thing that Matthias's student was working on was the idea that it is possible. 01:53:57 Roughly speaking, you'd encode enough functionality in this LC world so you represent all values as tagged-values, 01:54:09 and then use these tags to actually check for errors. 01:54:19 And that's the thing that (again, IIRC) turns out to be impossible. 01:55:32 -!- tupi [~david@186.205.37.15] has quit [Quit: Leaving] 01:55:41 If it is possible in lisp and scheme on von-neuman, why not in lambda calculus?! 01:56:24 Well, it is not possible in neither. At least I've never seen it done. 01:57:05 All the controlled environments do it. JVM, C#, Lisps, schemes, ruby, javascript, etc. 01:57:40 They all do that by isolating you completely from the underlying implementation -- i.e., you can certainly build a safe interpreter. 01:57:50 But you can't do it inside the language. 01:57:54 Yes. 01:58:09 That's obvious. 01:58:53 Wasn't obvious when they started, and if you read through SICP, it's kind of like going in the direction of their closure-based object system being a good basis for creating new types. 01:59:32 (But after I've seen some related horrors in that course, I gave up hope of that part making any sense...) 02:01:34 -!- pnkfelix [~Adium@c-71-225-45-140.hsd1.nj.comcast.net] has quit [Quit: Leaving.] 02:08:38 We've lost franki^ ? 02:11:15 -!- xwl_ [~user@nat/nokia/x-ueybckbfpufejhma] has quit [Remote host closed the connection] 02:12:24 I am here, I didn't want to disturb your interesting conversation.. :) 02:13:30 I've got a half-working solution here. As in, it works for '(foo x y) but not for bigger trees, something about trying to incrememnt 'foo. *mutter mutter* 02:16:16 Show your code! 02:17:38 Or just tell me how you do the recursive call on the left child? 02:19:11 http://paste.lisp.org/display/116160#2 There are probably several mistakes here, heh 02:19:21 I'm just eating for a minute... 02:22:02 franki^: This is almost correct. You forgot that the function number-leaves-with-counter must return a list with two values; the new tree, and the new counter. So you must also use let to collect the result of the second recursive call, and use the second new counter in the result of the function. 02:34:18 xwl_ [~user@nat/nokia/x-jmepjepfgiuwxaku] has joined #scheme 02:37:03 Okay, I'm nearly there! 02:40:11 -!- xwl_ [~user@nat/nokia/x-jmepjepfgiuwxaku] has quit [Remote host closed the connection] 02:41:38 pjb: This smells really close now... http://paste.lisp.org/display/116160#3 02:42:34 Oh, I think I see it! 02:42:51 The last cond pair doesn't return a counter! 02:43:30 Hrmmm 02:44:02 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Remote host closed the connection] 02:44:14 Yes. Now just wrap your tree in a list with the second new counter. 02:44:40 I tried returning (cadr right-result) as the return counter, but it doesn't quite work... 02:45:17 It just adds an extra number at the end It's so close to my desired output! 02:45:34 (list (list ...) (cadr right-result)) 02:46:08 Yeah, that's what I've got, but it returns ;Value 33: ((foo (bar 0 1) (baz 2 (quux 3 4))) 5) when I want ;Value 33: ((foo (bar 0 1) (baz 2 (quux 3 4)))) 02:46:25 I don't know where that 5's coming from 02:47:21 This is the last counter. 02:47:28 But remember this is the sub-function. 02:47:40 The main function will return the first element of this result: just the tree. 02:48:06 Oh, yes! 02:48:15 Thank you so much pjb! 02:48:34 Check my solution http://paste.lisp.org/display/116160#4 02:49:33 You could also have a look at how R5RS let you return multiple values (instead of using a list), and try to use that mechanism instead. 02:50:58 I'll look into that :) 02:51:57 Is there any reason that you used nested lets rather than let*? 02:55:22 xwl_ [~user@nat/nokia/x-ojbihwxyoclmuoer] has joined #scheme 02:59:48 -!- emma [~em@unaffiliated/emma] has quit [Read error: Operation timed out] 03:02:34 emma [~em@unaffiliated/emma] has joined #scheme 03:03:01 DrDuck [~duck@146.229.117.131] has joined #scheme 03:03:52 -!- DrDuck [~duck@146.229.117.131] has quit [Client Quit] 03:11:03 pnkfelix [~Adium@c-71-225-45-140.hsd1.nj.comcast.net] has joined #scheme 03:25:14 -!- aisa [~aisa@c-68-35-167-179.hsd1.nm.comcast.net] has quit [Ping timeout: 264 seconds] 03:31:52 aisa [~aisa@c-68-35-167-179.hsd1.nm.comcast.net] has joined #scheme 03:31:56 -!- aisa [~aisa@c-68-35-167-179.hsd1.nm.comcast.net] has quit [Client Quit] 03:35:34 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Quit: Leaving] 03:41:08 franki^: just for clarity. But let* would do perfectly well here. 03:44:36 pjb: (I'm just about to leave, but..) There's no technical reason then? I'm still a bit unsure about the specifics of let/let*/letrec 03:45:31 you know "let" 03:45:38 it just binds a bunch variables. 03:45:51 let* is similar, but binds them in order, so that later expressions can refer to earlier variables 03:46:07 letrec is magic: it makes it so that _earlier_ expressions can refer to _later_ variables. 03:46:12 QED. 03:46:14 _ 03:51:52 franki^: indeed, (let* ((a x) (b y)) z) is equivalent to (let ((a x)) (let ((b y)) z)). No difference. 03:53:02 timj_ [~timj@e176195079.adsl.alicedsl.de] has joined #scheme 03:54:24 Indeed, the reference R5RS let* macro just expands to that. 03:55:46 Of course, that further macroexpands to (((lambda (a) (lambda (b) z)) x) y) or something very much like it. :-P 03:55:58 -!- timj__ [~timj@e176197140.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds] 03:57:48 which expands to some turtles 03:58:22 ...I thought only Logo does that. 04:01:25 Not only. http://en.wikipedia.org/wiki/Turtles_all_the_way_down 04:01:40 vu3rdd [~vu3rdd@nat/cisco/x-ljftkxgfnbwoicug] has joined #scheme 04:04:07 Hehehehe. 04:05:30 -!- kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has quit [Quit: Leaving] 04:15:57 -!- pnkfelix [~Adium@c-71-225-45-140.hsd1.nj.comcast.net] has quit [Quit: Leaving.] 04:24:02 -!- dnm [~dnm@c-68-34-57-169.hsd1.va.comcast.net] has quit [Ping timeout: 264 seconds] 04:24:32 *franki^* returns 04:25:05 And, thanks for the tips guys. I do know let, but I wasn't sure if there were efficiency issues to consider or something 04:25:29 If what offby1 said is all I need to know, then I'm satisfied with my let skillz. :) 04:29:11 dnm [~dnm@c-68-34-57-169.hsd1.va.comcast.net] has joined #scheme 04:30:16 dnm_ [~dnm@c-68-34-57-169.hsd1.va.comcast.net] has joined #scheme 04:34:09 *shrug* I think it's close enough for gummint work. 04:34:53 kilimanjaro [~kilimanja@ip24-255-34-109.tc.ph.cox.net] has joined #scheme 04:34:53 -!- kilimanjaro [~kilimanja@ip24-255-34-109.tc.ph.cox.net] has quit [Changing host] 04:34:53 kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has joined #scheme 04:35:58 -!- dfeuer [~dfeuer@wikimedia/Dfeuer] has quit [Ping timeout: 245 seconds] 04:41:42 Well, we can be sure that there are many other things I'm more ignorant about, at least. :) 04:41:47 -!- kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has quit [Quit: Leaving] 04:42:11 kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has joined #scheme 04:42:29 i think that worked 04:42:34 what's the verdict? 04:43:13 Looks worky to me 04:43:49 ohh, sorry, wrong channel 04:44:42 But I think I found a workaround for freenode services being so slow, apparently you can set the server password as ":username password" and authenticate with nickserv quickly enough to actually be cloaked when you autojoin channels 04:46:04 Muy interesante 04:47:31 You can probably do it with SASL authentication, too. 04:47:36 seangrove [~user@c-71-198-44-87.hsd1.ca.comcast.net] has joined #scheme 04:48:11 I don't know whether that is specific to the Tor hidden service, though. 05:05:04 -!- pumpkin [~pumpkin@user-142hbak.cable.mindspring.com] has quit [Ping timeout: 272 seconds] 05:07:13 MichaelRaskin [~MichaelRa@195.178.216.22] has joined #scheme 05:11:41 -!- Caleb-- [~caleb@bzq-79-182-5-16.red.bezeqint.net] has quit [Ping timeout: 276 seconds] 05:12:51 jonrafkind [~jon@jonr5.dsl.xmission.com] has joined #scheme 05:15:28 Caleb-- [thedude@bzq-79-182-5-16.red.bezeqint.net] has joined #scheme 05:15:31 Since #scheme has become my new favourite channel, does anyone have any comments on this solution: http://paste.lisp.org/display/116188 ? 05:16:04 This time it actually works, however I'm always interested in finding better ways to do things. :) 05:20:13 franki^: number-elements doesn't use lst. 05:21:22 Oh, oops, I think that was me miscopying the question, sorry! 05:22:38 (define (increment-enumeration lst-of-couples) (mapcar (lambda (couple) (list (first couple) (+ 1 (second couple)))) lst-of-couples)) 05:23:32 Ah, I thought there might be a function to do that 05:23:38 *franki^* looks up mapcar.. 05:23:58 Sorry, in scheme it's called map. 05:24:11 I'm really a Common Lisper deguised as a schemer here ;-) 05:25:04 *eli* stares intently at offby1 05:25:14 Ah, but, I tried map, but it seemed to me to not quite work the way I wanted it to.. 05:25:20 -!- metasyntax [~taylor@72.86.89.174] has quit [Ping timeout: 276 seconds] 05:25:27 You can apply map to number-element-from too. 05:25:33 *franki^* tries again 05:26:02 ,rudybot init r5rs 05:26:09 rudybot: init r5rs 05:26:10 pjb: your r5rs sandbox is ready 05:26:35 rudybot: eval (define (increment-enumeration lst-of-couples) (mapcar (lambda (couple) (list (first couple) (+ 1 (second couple)))) lst-of-couples)) 05:26:47 rudybot: eval (define (increment-enumeration lst-of-couples) (map (lambda (couple) (list (first couple) (+ 1 (second couple)))) lst-of-couples)) 05:26:50 ,rudybot eval (define (increment-enumeration lst-of-couples) (map (lambda (couple) (list (first couple) (+ 1 (second couple)))) lst-of-couples)) 05:27:25 pjb: If you use not-rudy-bot instead of rudybot, you get feedback when you define things. :-) 05:27:39 Ok. 05:27:44 *eli* coughs noisily 05:27:57 Poor eli. 05:28:23 rudybot: eval (increment-enumeration '((a 1) (b 2) (c 3))) 05:28:24 pjb: ; Value: {{a 2} {b 3} {c 4}} 05:28:27 pjb: rudybot evaluated that the first time (when you said "rudybot: eval blah"), just didn't show any output. 05:28:39 Yes, I see now. 05:32:18 Okay, I've got it working with map now. I think my problem was in g I didn't have it returning (list lst1) but only lst1 when I tested with map 05:32:43 But I didn't recognise that was a problem until I implemented it without map. 05:36:35 Hm, I need to go and have a shower before bed. Thanks again for your help pjb, and everyone else. 05:36:43 #scheme is awesome :) 05:37:13 Good night! 05:38:20 metasyntax [~taylor@72.86.89.174] has joined #scheme 06:02:26 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Remote host closed the connection] 06:02:38 -!- snorble [~snorble@s83-179-14-105.cust.tele2.se] has quit [Read error: Operation timed out] 06:02:53 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 06:03:45 snorble [~snorble@s83-179-14-105.cust.tele2.se] has joined #scheme 06:03:46 pumpkin [~pumpkin@user-142hbak.cable.mindspring.com] has joined #scheme 06:10:10 -!- futilius [~otheruser@2001:470:d:128:216:3eff:fe86:c70e] has quit [Read error: Operation timed out] 06:10:27 futilius [~otheruser@2001:470:d:128:216:3eff:fe86:c70e] has joined #scheme 06:12:11 schmir [~schmir@mail.brainbot.com] has joined #scheme 06:18:24 -!- futilius [~otheruser@2001:470:d:128:216:3eff:fe86:c70e] has quit [Read error: Operation timed out] 06:18:29 futilius [~otheruser@2001:470:d:128:216:3eff:fe86:c70e] has joined #scheme 07:00:56 -!- jonrafkind [~jon@jonr5.dsl.xmission.com] has quit [Ping timeout: 240 seconds] 07:09:52 -!- wgd [~will@76-205-0-91.lightspeed.stlsmo.sbcglobal.net] has quit [Ping timeout: 252 seconds] 07:12:15 <_danb_> not-rudy-bot: quote 07:12:16 _danb_: let's write GLemacs 07:12:52 `micro [~micro@www.bway.net] has joined #scheme 07:15:32 wgd [~will@76-205-0-91.lightspeed.stlsmo.sbcglobal.net] has joined #scheme 07:20:31 -!- REPLeffect [~REPLeffec@69.54.115.254] has quit [Ping timeout: 265 seconds] 07:30:11 mmc [~michal@cs27124149.pp.htv.fi] has joined #scheme 07:34:04 REPLeffect [~REPLeffec@69.54.115.254] has joined #scheme 07:41:13 -!- emma [~em@unaffiliated/emma] has quit [Ping timeout: 252 seconds] 07:46:20 gravicappa [~gravicapp@ppp85-141-167-37.pppoe.mtu-net.ru] has joined #scheme 08:05:29 slom [~sloma@port-87-234-239-162.static.qsc.de] has joined #scheme 08:19:34 -!- slom [~sloma@port-87-234-239-162.static.qsc.de] has quit [Read error: Connection reset by peer] 08:20:10 slom [~sloma@port-87-234-239-162.static.qsc.de] has joined #scheme 08:27:32 -!- wbooze` [~user@xdsl-78-34-104-226.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 08:28:06 -!- homie` [~user@xdsl-78-34-104-226.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 08:29:18 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 08:30:11 wbooze [~user@xdsl-78-34-104-226.netcologne.de] has joined #scheme 08:31:15 homie [~user@xdsl-78-34-104-226.netcologne.de] has joined #scheme 08:37:25 -!- jengle [~jengle@64-252-187-48.adsl.snet.net] has quit [Quit: jengle] 08:49:43 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Ping timeout: 245 seconds] 08:50:24 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 08:55:37 -!- kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has quit [Ping timeout: 240 seconds] 09:01:02 -!- homie [~user@xdsl-78-34-104-226.netcologne.de] has quit [Read error: Connection reset by peer] 09:04:11 homie [~user@xdsl-78-34-104-226.netcologne.de] has joined #scheme 09:04:55 pavelludiq [~quassel@87.246.31.34] has joined #scheme 09:09:06 rdd [~rdd@c83-250-48-164.bredband.comhem.se] has joined #scheme 09:09:12 -!- homie [~user@xdsl-78-34-104-226.netcologne.de] has quit [Read error: Connection reset by peer] 09:10:25 homie [~user@xdsl-78-34-104-226.netcologne.de] has joined #scheme 09:27:22 -!- pumpkin [~pumpkin@user-142hbak.cable.mindspring.com] has quit [Ping timeout: 252 seconds] 09:33:07 masm [~masm@2.80.144.108] has joined #scheme 09:45:42 HG` [~HG@xdsl-92-252-93-93.dip.osnanet.de] has joined #scheme 09:51:48 -!- gravicappa [~gravicapp@ppp85-141-167-37.pppoe.mtu-net.ru] has quit [Remote host closed the connection] 10:07:34 -!- homie [~user@xdsl-78-34-104-226.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:18:58 -!- wbooze [~user@xdsl-78-34-104-226.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:27:55 Blkt [~user@160.80.132.241] has joined #scheme 10:28:56 good day everyone 10:29:20 homie [~user@xdsl-78-34-104-226.netcologne.de] has joined #scheme 10:31:48 wbooze [~user@xdsl-78-34-104-226.netcologne.de] has joined #scheme 10:46:13 kuribas [~user@94-226-139-12.access.telenet.be] has joined #scheme 10:50:18 -!- vu3rdd [~vu3rdd@nat/cisco/x-ljftkxgfnbwoicug] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:59:57 -!- pavelludiq [~quassel@87.246.31.34] has quit [Remote host closed the connection] 11:08:26 mejja [~chatzilla@c-14bee555.023-82-73746f38.cust.bredbandsbolaget.se] has joined #scheme 11:08:49 -!- kuribas [~user@94-226-139-12.access.telenet.be] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 11:13:42 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #scheme 11:19:22 -!- mejja [~chatzilla@c-14bee555.023-82-73746f38.cust.bredbandsbolaget.se] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]] 11:21:42 -!- _danb_ [~user@124-149-55-13.dyn.iinet.net.au] has quit [Remote host closed the connection] 11:32:42 Axius [~darkstar@92.84.24.202] has joined #scheme 11:33:29 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 11:43:33 gravicappa [~gravicapp@80.90.116.82] has joined #scheme 11:45:20 -!- Blkt [~user@160.80.132.241] has quit [Ping timeout: 260 seconds] 11:49:00 homie` [~user@xdsl-78-34-206-4.netcologne.de] has joined #scheme 11:49:00 -!- homie [~user@xdsl-78-34-104-226.netcologne.de] has quit [Read error: Operation timed out] 11:49:19 wbooze` [~user@xdsl-78-34-206-4.netcologne.de] has joined #scheme 11:51:26 -!- wbooze [~user@xdsl-78-34-104-226.netcologne.de] has quit [Ping timeout: 276 seconds] 12:05:53 pavelludiq [~quassel@87.246.31.34] has joined #scheme 12:09:05 -!- Axius [~darkstar@92.84.24.202] has quit [Ping timeout: 255 seconds] 12:11:25 -!- homie` [~user@xdsl-78-34-206-4.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:12:09 -!- wbooze` [~user@xdsl-78-34-206-4.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:21:08 Axius [~darkstar@92.85.218.51] has joined #scheme 12:40:30 How do I run a scm file? 12:49:25 -!- HG` [~HG@xdsl-92-252-93-93.dip.osnanet.de] has quit [Quit: Leaving.] 12:51:19 -!- jao [~user@141.Red-79-145-118.dynamicIP.rima-tde.net] has quit [Ping timeout: 240 seconds] 12:51:45 -!- Axius [~darkstar@92.85.218.51] has quit [Quit: Leaving] 12:53:30 (load "file.scm") 12:58:01 homie [~user@xdsl-78-34-206-4.netcologne.de] has joined #scheme 13:01:51 wbooze [~user@xdsl-78-34-206-4.netcologne.de] has joined #scheme 13:02:21 Blkt [~user@160.80.132.241] has joined #scheme 13:14:13 -!- Axsuul [~someone@97-93-99-133.static.mtpk.ca.charter.com] has quit [Ping timeout: 250 seconds] 13:25:52 vu3rdd [~vu3rdd@122.166.167.81] has joined #scheme 13:26:20 -!- rmrfchik [~paul@195.191.11.247] has quit [Ping timeout: 276 seconds] 13:26:47 rmrfchik [~paul@195.191.11.247] has joined #scheme 13:31:06 gcartier [~gcartier@modemcable026.84-70-69.static.videotron.ca] has joined #scheme 13:33:39 mcf [~mcf@homenet-ukhta.ru] has joined #scheme 13:35:27 -!- mcf [~mcf@homenet-ukhta.ru] has left #scheme 13:42:36 kuribas [~user@d54C43270.access.telenet.be] has joined #scheme 13:43:12 -!- ecraven [~user@140.78.42.213] has quit [Quit: bbl] 13:46:58 -!- schmir [~schmir@mail.brainbot.com] has quit [Remote host closed the connection] 13:46:59 rpg [~rpg@216.243.156.16.real-time.com] has joined #scheme 13:49:09 ecraven [~user@140.78.42.213] has joined #scheme 13:49:57 -!- pavelludiq [~quassel@87.246.31.34] has quit [Remote host closed the connection] 14:07:22 tupi__ [~david@139.82.89.24] has joined #scheme 14:07:27 -!- dnm_ [~dnm@c-68-34-57-169.hsd1.va.comcast.net] has quit [Ping timeout: 252 seconds] 14:12:16 -!- MichaelRaskin [~MichaelRa@195.178.216.22] has quit [*.net *.split] 14:12:16 -!- xwl_ [~user@nat/nokia/x-ojbihwxyoclmuoer] has quit [*.net *.split] 14:12:16 -!- Euthydemus [~euthydemu@vaxjo3.23.cust.blixtvik.net] has quit [*.net *.split] 14:12:16 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [*.net *.split] 14:12:16 -!- firecrow8 [~fcrow@69.38.169.34] has quit [*.net *.split] 14:12:16 -!- minion [~minion@common-lisp.net] has quit [*.net *.split] 14:12:17 -!- pothos [~pothos@111-240-211-11.dynamic.hinet.net] has quit [*.net *.split] 14:12:17 -!- joast [~rick@76.178.178.72] has quit [*.net *.split] 14:12:17 -!- cky [~cky@car.spillville.com] has quit [*.net *.split] 14:12:17 -!- Axioplase_ [~Axioplase@fortigate.kb.ecei.tohoku.ac.jp] has quit [*.net *.split] 14:12:17 -!- elf [elf@antenora.aculei.net] has quit [*.net *.split] 14:12:17 -!- C-Keen [ckeen@pestilenz.org] has quit [*.net *.split] 14:14:09 Axsuul [~someone@97-93-99-133.static.mtpk.ca.charter.com] has joined #scheme 14:16:28 drdo [~user@98.192.108.93.rev.vodafone.pt] has joined #scheme 14:29:39 -!- wbooze [~user@xdsl-78-34-206-4.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 14:29:50 -!- homie [~user@xdsl-78-34-206-4.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 14:33:39 MichaelRaskin [~MichaelRa@195.178.216.22] has joined #scheme 14:33:39 xwl_ [~user@nat/nokia/x-ojbihwxyoclmuoer] has joined #scheme 14:33:39 Euthydemus [~euthydemu@vaxjo3.23.cust.blixtvik.net] has joined #scheme 14:33:39 antoszka [~antoszka@unaffiliated/antoszka] has joined #scheme 14:33:39 minion [~minion@common-lisp.net] has joined #scheme 14:33:39 pothos [~pothos@111-240-211-11.dynamic.hinet.net] has joined #scheme 14:33:39 joast [~rick@76.178.178.72] has joined #scheme 14:33:39 cky [~cky@car.spillville.com] has joined #scheme 14:33:39 Axioplase_ [~Axioplase@fortigate.kb.ecei.tohoku.ac.jp] has joined #scheme 14:33:39 elf [elf@antenora.aculei.net] has joined #scheme 14:33:39 C-Keen [ckeen@pestilenz.org] has joined #scheme 14:36:18 bweaver [~user@75-148-111-133-Chattanooga.hfc.comcastbusiness.net] has joined #scheme 14:39:15 -!- mmc [~michal@cs27124149.pp.htv.fi] has quit [Quit: Leaving.] 14:39:48 jonrafkind [~jon@jonr5.dsl.xmission.com] has joined #scheme 14:46:38 -!- githogori [~githogori@adsl-66-123-22-146.dsl.snfc21.pacbell.net] has quit [Quit: Leaving] 14:48:28 -!- kuribas [~user@d54C43270.access.telenet.be] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 14:59:41 -!- gravicappa [~gravicapp@80.90.116.82] has quit [Remote host closed the connection] 15:03:40 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 15:04:28 firecrow8 [~fcrow@69.38.169.34] has joined #scheme 15:09:52 fradgers- [~fradgers-@5e04acf0.bb.sky.com] has joined #scheme 15:13:05 not-rudy-bot: uptime 15:13:05 offby1: I've been up for one day; this tcp/ip connection has been up for one day 15:13:08 not-rudy-bot: source 15:13:09 offby1: git clone git://github.com/offby1/rudybot.git 15:13:12 not-rudy-bot: version 15:13:13 offby1: 8063aa7 15:26:14 homie [~user@xdsl-78-34-206-4.netcologne.de] has joined #scheme 15:30:30 -!- Jafet [~Jafet@unaffiliated/jafet] has quit [Ping timeout: 260 seconds] 15:34:29 wbooze [~user@xdsl-78-34-206-4.netcologne.de] has joined #scheme 15:43:01 -!- seangrove [~user@c-71-198-44-87.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 15:45:08 -!- cipher [~cipher@c-76-24-16-225.hsd1.ma.comcast.net] has quit [Ping timeout: 245 seconds] 15:45:46 pumpkin [~pumpkin@user-142hbak.cable.mindspring.com] has joined #scheme 15:48:13 mejja [~chatzilla@c-14bee555.023-82-73746f38.cust.bredbandsbolaget.se] has joined #scheme 16:01:56 -!- Blkt [~user@160.80.132.241] has quit [Quit: Error: do not makunbound t please!] 16:15:38 pavelludiq [~quassel@87.246.31.34] has joined #scheme 16:18:35 -!- eno [~eno@nslu2-linux/eno] has quit [Ping timeout: 276 seconds] 16:20:04 eno [~eno@nslu2-linux/eno] has joined #scheme 16:33:02 -!- bzzbzz [~franco@modemcable240.34-83-70.mc.videotron.ca] has quit [Ping timeout: 264 seconds] 16:38:29 klovett [~klovett@c-67-180-97-38.hsd1.ca.comcast.net] has joined #scheme 16:42:50 -!- jonrafkind [~jon@jonr5.dsl.xmission.com] has quit [Ping timeout: 255 seconds] 16:58:51 jengle [~jengle@64-252-187-48.adsl.snet.net] has joined #scheme 16:59:15 jonrafkind [~jon@crystalis.cs.utah.edu] has joined #scheme 17:00:39 -!- slom [~sloma@port-87-234-239-162.static.qsc.de] has quit [Remote host closed the connection] 17:09:34 jewel [~jewel@196-215-88-116.dynamic.isadsl.co.za] has joined #scheme 17:26:03 aisa [~aisa@c-68-35-167-179.hsd1.nm.comcast.net] has joined #scheme 17:29:43 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Ping timeout: 245 seconds] 17:31:20 Adamant [~Adamant@unaffiliated/adamant] has joined #scheme 17:33:31 -!- tupi__ [~david@139.82.89.24] has quit [Quit: Leaving] 17:36:02 -!- pumpkin is now known as mplus 17:37:26 femtoo [~femto@95-89-197-196-dynip.superkabel.de] has joined #scheme 17:38:58 ski [~slj@c-2911e055.1149-1-64736c10.cust.bredbandsbolaget.se] has joined #scheme 17:42:37 -!- mplus is now known as copumpkin 17:48:40 saac [~saac@unaffiliated/sergio/x-8197433] has joined #scheme 17:53:43 saac_ [~saac@unaffiliated/sergio/x-8197433] has joined #scheme 17:53:48 -!- saac_ [~saac@unaffiliated/sergio/x-8197433] has quit [Client Quit] 17:55:39 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 17:57:30 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Remote host closed the connection] 18:04:09 -!- mejja [~chatzilla@c-14bee555.023-82-73746f38.cust.bredbandsbolaget.se] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.12/20101026210630]] 18:04:34 femtooo [~femto@95-89-197-196-dynip.superkabel.de] has joined #scheme 18:04:55 elderK [~k@pdpc/supporter/active/elderk] has joined #scheme 18:04:57 -!- klovett [~klovett@c-67-180-97-38.hsd1.ca.comcast.net] has quit [Quit: klovett] 18:05:57 gravicappa [~gravicapp@ppp91-78-229-44.pppoe.mtu-net.ru] has joined #scheme 18:08:05 -!- femtoo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Ping timeout: 265 seconds] 18:11:19 bzzbzz [~franco@modemcable240.34-83-70.mc.videotron.ca] has joined #scheme 18:12:35 -!- MichaelRaskin [~MichaelRa@195.178.216.22] has quit [Ping timeout: 240 seconds] 18:13:46 kuribas [~user@d54C43270.access.telenet.be] has joined #scheme 18:14:09 kilimanjaro [~kilimanja@ip24-255-34-109.tc.ph.cox.net] has joined #scheme 18:14:10 -!- kilimanjaro [~kilimanja@ip24-255-34-109.tc.ph.cox.net] has quit [Changing host] 18:14:10 kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has joined #scheme 18:15:01 stis [~stis@1-1-1-39a.veo.vs.bostream.se] has joined #scheme 18:35:38 -!- chturne [~chturne@nas45-44.york.ac.uk] has quit [Ping timeout: 255 seconds] 18:39:22 jao [~user@141.Red-79-145-118.dynamicIP.rima-tde.net] has joined #scheme 18:51:23 -!- Adamant [~Adamant@unaffiliated/adamant] has quit [Ping timeout: 245 seconds] 18:51:33 dnm_ [~dnm@static-71-166-174-24.washdc.east.verizon.net] has joined #scheme 18:54:22 mmc [~michal@cs27124149.pp.htv.fi] has joined #scheme 19:04:24 Adamant [~Adamant@unaffiliated/adamant] has joined #scheme 19:07:33 -!- elderK [~k@pdpc/supporter/active/elderk] has quit [Remote host closed the connection] 19:09:23 elderK [~k@pdpc/supporter/active/elderk] has joined #scheme 19:11:40 githogori [~githogori@67-207-117-6.static.wiline.com] has joined #scheme 19:11:54 -!- githogori [~githogori@67-207-117-6.static.wiline.com] has quit [Remote host closed the connection] 19:16:57 -!- fradgers- [~fradgers-@5e04acf0.bb.sky.com] has quit [Ping timeout: 250 seconds] 19:20:58 -!- jewel [~jewel@196-215-88-116.dynamic.isadsl.co.za] has quit [Ping timeout: 245 seconds] 19:21:32 githogori [~githogori@67-207-117-6.static.wiline.com] has joined #scheme 19:23:25 klovett [~klovett@c-67-180-97-38.hsd1.ca.comcast.net] has joined #scheme 19:28:36 Quadrescence [~Quad@unaffiliated/quadrescence] has joined #scheme 19:39:59 -!- vu3rdd [~vu3rdd@122.166.167.81] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:41:44 -!- githogori [~githogori@67-207-117-6.static.wiline.com] has quit [Remote host closed the connection] 19:47:53 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 19:48:52 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Remote host closed the connection] 19:49:32 choas [~lars@p578F6F42.dip.t-dialin.net] has joined #scheme 19:51:36 -!- kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has quit [Quit: Leaving] 19:51:48 githogori [~githogori@67-207-117-6.static.wiline.com] has joined #scheme 19:54:16 jcowan [c6b912cf@gateway/web/freenode/ip.198.185.18.207] has joined #scheme 19:55:28 I'm trying to work out what the best representation in WG2 Scheme is for an instant of time. I have several different models available: 19:55:49 POSIX has 32-bit or 64-bit signed representation of seconds. 19:55:59 SRFI 19 has an unbounded representation of nanoseconds. 19:56:07 Java has a 64-bit signed representation of milliseconds. 19:56:38 Anyone have any ideas what the Right Thing is? 19:56:43 TAI64 has 64-bit signed representation of seconds in a way that handles leap seconds in a sane way. 19:56:52 i.e., by not ignoring them. 19:57:52 That's a separate issue I'm not currently concerned with. 19:58:08 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 19:59:47 The interesting thing about TAI64 is that it has two extensions: TAI64N (TAI64 + nanosecond counter), and TAI64NA (TAI64N + attosecond counter). I don't know if you want to handle three separate datatypes, but this way people can tailor their memory usage against their precision needs. 20:00:12 (nanosecond and attosecond counters are each 32 bits.) 20:00:14 But okay, I'll add 64-bit representation of seconds, nanoseconds, and (gak) attoseconds. 20:00:20 Hahahahaha. 20:00:35 there's really no justification for having it be bounded in Scheme 20:00:44 Actually, once you get far enough away from the epoch, you can forget time periods shorter than a year (and even they don't make much sense when you are *very* far from the epoch). 20:01:39 CL has an unbounded representation of seconds, but a different epoch. 20:02:49 jcowan, what do you mean "forget time periods"? 20:03:40 I mean that calendars don't work any more when you get past historical time and into geological time, as 64-bit representations allow. 20:06:15 Java's 64-bit representation of milliseconds has a total range of almost 600 million years, which takes us back to the Permian Extinction. 20:09:10 If I understand this equation correctly, the correction factor for secular change in the year is -6.2e-6*T^3, where T is the number of centuries backward. 20:09:42 And even that, I suspect, does not work any more when you are looking at millions of centuries. 20:10:50 On the other hand, seconds since the epoch is already bigger than a fixnum on 32-bit systems. 20:13:35 it's true that if x seconds = x/k years, k depends on the number of seconds and when they occur 20:13:51 but that doesn't mean that unbound quantities of seconds don't make sense 20:14:30 They make sense as durations, but they aren't usable in practice as time instants. 20:14:56 jcowan, i don't think that's true at all 20:15:25 For example? 20:15:36 seangrove [~user@70-36-236-168.dsl.static.sonic.net] has joined #scheme 20:15:36 the term "30 million years ago" refers to a quantity of seconds 20:15:45 -!- pavelludiq [~quassel@87.246.31.34] has quit [Read error: Connection reset by peer] 20:16:06 and we can define instatn relative to the epoch 20:16:11 gtg 20:17:48 30 million years ago is rather a time interval, which could be defined to mean [25,35) million years ago, or [29.5,30.5) million years ago, and so on and so forth. :-P 20:17:53 That's just it: it refers to *some* quantity of seconds, but we don't know how many. 20:18:15 "30 million years" is an interval; "30 million years ago" is hypothetically an instant. 20:18:41 Hypothetically, because we don't know what instant it is. 20:18:45 Indeed. 20:18:51 MichaelRaskin [~MichaelRa@195.91.224.225] has joined #scheme 20:20:24 I'd like instants and durations to be exact Scheme integers so that I don't have to define special arithmetics on them. 20:21:16 But I'm leaning toward allowing implementations to use inexact integers as well, within the range (typically 2^53) in which every inexact integer has a representation. Boxed flonums are typically smaller than 2-bigit bignums and more efficient to do arithmetic on. 20:21:29 Exact Scheme _integers_, or exact Scheme numbers? (including rational) 20:21:51 Integers, quantizing time to milliseconds or nanoseconds or whatever. 20:21:58 *nods* 20:24:45 If you had a sane numeric tower to work with, I'd suggest using rationals to avoid worrying about whether to use milliseconds, nanoseconds, or whatever. 20:25:22 (Or has WG1 adopted a requirement for a full numeric tower?) 20:27:05 2^53 milliseconds would be 280,000 years, well into the Pleistocene. 20:27:10 WG1 has not adopted such a requirement. 20:27:44 The trouble with exact rational arithmetic is that performance goes to hell. 20:28:53 -!- saccade [~saccade@209-6-54-113.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Quit: This computer has gone to sleep] 20:29:23 laevus [~marc@dsl-185-157-180.dynamic.wa.co.za] has joined #scheme 20:30:08 For what kinds of applications is this a concern? 20:34:14 I think the best answer I can give is: in applications where results (final or intermediate) are fairly complex numerical functions of the inputs. 20:34:56 When you do such applications with flonums, they are performant but may produce gibberish. When you use rationals, you get exact results but may have to wait a lifetime to get them. 20:35:27 Anecdotally, I remember a story about a PLT application which ran ~2 orders of magnitude faster when a single decimal point was inserted judiciously. 20:36:44 For what kind of date arithmetic is a concern, and if inexact arithmetic on dates is truly desired, why can't the application use exact->inexact and inexact->exact? 20:37:50 -!- laevus [~marc@dsl-185-157-180.dynamic.wa.co.za] has quit [Read error: No route to host] 20:38:21 laevus [~marc@dsl-185-157-180.dynamic.wa.co.za] has joined #scheme 20:41:50 -!- laevus [~marc@dsl-185-157-180.dynamic.wa.co.za] has quit [Client Quit] 20:41:59 I suppose, although it's nice to take advantage of the fact that flonum arithmetic on integers is as exact (sometimes more exact) than fixnum arithmetic. 20:44:16 What is this `fixnum arithmetic' nonsense? 20:45:01 It's what you get when you define a standard around an implementation limitation. 20:45:12 It's permitted by R5RS. 20:45:26 That's a bug in the R5RS. 20:45:27 That was a mistake. 20:46:02 Seriously, it's 2010. We've had performant arbitrary-precision integer and rational arithmetic for how many decades now? 20:47:08 Technically, *wrapping* fixnum arithmetic is not permitted, but overflow-signaling and overflow-to-flonum are both permitted. 20:47:38 Even a naive implementation is unlikely to be a bottleneck if the rest of the implementation of Scheme is as naive as its implementation of unbounded exact integer arithmetic. 20:48:12 But this is a discussion we've had already, and I don't wish to repeat myself. 20:48:17 No standard has any business mentioning `fixnums' except as an informational note about possible implementation techniques. 20:48:36 Implementations that execute on itty-bitty chips can afford to be very smart; what they can't afford is to have too many libraries. 20:49:04 So there is nothing self-contradictory about having a sophisticated compiler but almost no library routines. 20:49:16 There's little reason for that informational note either. The standard should define a language. If the standard authors feel the need to provide advice to implementors, they should do so in a non-normative implementation advice document. 20:49:16 Fine. They can report violations of implementation restrictions. That doesn't make it any less dunderheaded to mention fixnums in any standard. 20:49:41 chandler, er, yes, that's what an `informational' note is about -- a non-normative note. 20:50:09 I was suggesting that even such notes don't belong in the standard, but that's a quibble. 20:50:27 OK, sure. 20:51:39 Well, WG2 (which is what I'm dealing with here, I don't expect a time library of any sort in WG1) will have fixnum-only and flonum-only libraries anyway, dunderheaded or not. 20:52:22 jcowan: I have a product that runs on an itty-bitty chip. I've explored the possibility of adding an extension language to the product, and I've been weighing various different options. One conclusion I've come to is that even if the *language* used is or resembles a commonly used, standard language like Scheme or JavaScript, very few programs written in this language will succesfully execute in the "itty-bitty" environment anyway. 20:52:48 pretty much. 20:53:04 -!- mmc [~michal@cs27124149.pp.htv.fi] has quit [Ping timeout: 240 seconds] 20:53:06 C and Forth exist for a reason, and that reason is tiny chips. 20:53:08 Thus, adding implementation restrictions to the standard language makes almost no difference, since the value in using a standard language is in programmer familiarity, not in the ability to run already extant code written in a standard language. 20:53:25 I will say this 20:53:39 I'm not sure that's as true for 16-bit and 32-bit chips 20:53:43 If your definition of "itty bitty" has a few megabytes of SRAM attached to it (as I've often seen these days), unbounded exact integers are hardly a problem. 20:53:55 and I think the embedded industry is moving toward there 20:54:11 32-bit chips are rapidly supplanting 8-bit chips even in situations where very little memory is available. 20:54:18 yes. 20:54:50 the STM32, PIC32, etc. 20:54:58 Glad to hear that. 20:55:03 C makes even more sense on 32-bit chips than it does on an 8-bit micro. C compilers for 8-bit micros often wind up doing too much register or stack shuffling. 20:55:26 chandler: not as much on RISCy chips like AVR, IIRC 20:55:28 but yeah 20:55:38 I never used an AVR, actually. :-) 20:55:46 that's your problem :P 20:55:51 they're really nice 20:55:54 Ah. Well, I'm on an ARM7TDMI now. 20:55:59 yeah 20:56:06 Thumb/Thumb2 FTW 20:56:17 Is there anyone on WG1 or WG2 who actually has substantial, up-to-date experience working with `itty-bitty' environments? 20:56:29 As to the numeric tower question, I put together a page describing 10 numeric towers that are at least non-pathological, out of 16 possible based on four binary oppositions: exactness-preserving, ratios, inexact, and complex. 20:56:30 It would be, if the chip I'm using actually could run thumb code from internal flash. :-( 20:56:34 chandler: ... unless you're making a realtime visualization app, or a game where code that runs five times slower matters, in which case your language is rendered worthless because of numerous performance compromises. 20:56:37 how many EE's are on the comittee? 20:56:53 Obfuscate: I can't quite tell what that refers to. 20:56:58 Obfuscate: if you're doing that, you don't use a itty-bitty chip. 20:57:13 at least in 2010. 20:57:14 I don't know the answers to the questions about the committee, but the participants are publicly listed. 20:57:21 even DS and PSP's use high end ARMs. 20:57:32 The PSP uses a 32-bit MIPS. 20:57:36 ah 20:57:39 same thing 20:57:40 Adamant: Let's say you're using a typical c2q setup with 4gb ram: it still applies. 20:57:57 Obfuscate: I still don't understand what you're talking about. 20:58:00 Obfuscate: for that setup you can hit it with a smart compiler to optimize to fixnum 20:58:03 chandler: In regard to programmer familiarity and implementation restrictions not mattering. 20:58:07 problem goes away. 20:58:19 The comment was about subsetting the language for a tiny environment. Was that unclear from context? 20:58:23 Adamant: Not if your representation of times forces you to deal with numbers that don't fit in fixnums. That's my point. 20:58:25 mmc [~michal@cs27120227.pp.htv.fi] has joined #scheme 20:58:35 that is a good point. 20:58:43 chandler: Ah, yes, it was. I thought you were making a general point. 20:58:48 And yes, "itty-bitty" is a relative term. WHole server farms are "itty-bitty" with respect to certain requirements. 20:59:17 That's a silly point. Whole server farms can easily run an implementation which includes unbounded exact integer arithmetic. 20:59:19 Adamant: It doesn't fix the problem, because integer wraparound is a defining characteristic of fixnums and users need to be explicitly aware of it. 20:59:20 yes, if you're Google or Amazon and a server farm is just a "distributed compute node" for you :P 20:59:56 jcowan, to return to our earlier discussion, 30 million years ago is not typically measured by calculating how many sun rotations we're talking about 20:59:57 Obfuscate: you can throw errors for maluse of fixnums. 20:59:58 Obfuscate: If it wasn't already known how to do unboxed modular word-size arithmetic correctly in a language with unbounded exact integers, I'd consider your point to be valid. 21:00:00 I don't think it matters much with giant server farms, since while scaling one is expensive, it is still /possible/. 21:00:03 Integer wraparound may be a defining characteristic of fixnum arithmetic, but it's often a totally useless one, unless you particularly wanted arithmetic modulo 2^29 or modulo 2^61. 21:00:15 Furthermore, if you want floats, you know where to find them. 21:00:22 if you're using overflow intentionally, I don't care 21:00:30 it's a misfeature 21:00:34 but rather by a computation that involves seconds 21:01:14 Fare [~Fare@ita4fw1.itasoftware.com] has joined #scheme 21:01:23 and it's ridiculous that in 2010 anyone is considering writing a language standard with potentially bounded integers 21:01:53 also, anyone that has to create a situation where they need to care about fixnum overflow that can't be handle by promotion to bignum already knows about overflow 21:01:58 Riastradh: It's often useful when working modulo 2^32 or 2^64, but as I've already pointed out, it's already known how to do this arithmetic without boxing or other extra overhead without sacrificing a full numeric tower. 21:02:09 Let me know what application you're writing whose performance is predicated upon time- or space-efficient representations of times and durations, jcowan. 21:02:40 chandler, I know of only one Scheme system in which *fixnum* arithmetic is modulo 2^32, but that Scheme system doesn't count... 21:03:17 jcowan, once you've identified that application, we can talk about what operations it needs to perform fast and how its memory use needs to scale. 21:03:17 I think having the option to explictly use fixnum is good 21:03:54 but it's mostly for weird optimization cases the compiler can't be expected to catch 21:03:59 Riastradh: That would be relevant if I were wearing an application-developer hat, but I'm not. 21:04:08 I'm not even wearing a library-developer hat. 21:04:35 Well, then you should put on a finding-application-developers-to-learn-their-requirements-and-constraints hat. 21:04:40 chandler: I don't see what the point of simulating fixnum arithmetic with unbounded numbers is vs just explicitly providing a fixnum type. 21:04:57 Obfuscate, when was the last time you wanted arithmetic modulo 2^29? 21:05:24 jcowan: Yes, you are purporting to wear this hat. You have made the claim that performance is more important than exactness to application developers. 21:05:26 Or, arithmetic that might be modulo 2^29, or modulo 2^28, or modulo 2^61, or modulo 2^58, but you don't know which? 21:05:48 chandler: it is, but to different groups. 21:06:07 fixnums are a result of real hardware constraints 21:06:11 Obfuscate: SBCL provides unboxed, efficient 32-bit and 64-bit modular arithmetic. How do I get both of those with a fixnum type 21:06:15 ? 21:06:21 Riastradh: ... only when dealing with bitmasks, and I don't remember when, but those aren't the cases. 21:06:23 Fixnums are an implementation detail leaking to the language user. 21:06:41 Obfuscate: Scheme is not a great language to do bitmasks in, honestly. 21:06:56 Why not? 21:07:00 chandler: maybe, but they must be considered at some level. 21:07:12 Obfuscate, why do you care what the modulus is if you're dealing with bit masks? If the indices of the bits don't exceed the modulus of the arithmetic, you won't even notice that the arithmetic is modular. 21:07:13 chandler: because it's not really meant to do bit-twiddling in 21:07:21 C or Erlang's bit syntax is much nicer 21:07:29 Define a better syntax, then. 21:07:37 Erlang's bit syntax. 21:07:38 Scheme is meant to do anything you define it to mean to do. 21:07:39 there. 21:07:51 yes, any language can do anything any other language can do 21:08:20 The level at which fixnums must be considered is entirely within the implementation, which does include a user profiling how a program runs on a particular implementation. 21:08:36 that doesn't mean Scheme has a nice setup like Erlang's right now, or that it's easy to do without some parsing magic since the requirements for that syntax conflict with the requirement for parens everywhere 21:08:50 Oh, this is a number-of-keystrokes argument. 21:08:53 How dull. 21:09:02 this isn't an argument in the first place 21:09:29 Riastradh: Knowing the modulus is helpful for shuffling bits around, such as in an implementation of ternary arithmetic on binary computers. 21:09:32 You are making the argument that Scheme is not well suited to bit twiddling because the syntax is too verbose. Have I misread your claim? 21:09:34 Adamant, OK, here's how it'll look in Scheme: (binary (3 a) (2 b) (1 c)), an expression evaluating to a bit string of length 6 whose high-order 3 bits are given by the expression a, whose next 2 bits are given by the expression b, and whose low-order bit is given by the expression c. 21:09:35 it's just a statement of my opinion and observations. you are free to substitute your own reality for mine. 21:10:12 Riastradh: that could work. 21:10:15 Adamant, happily, I can implement this syntax straightforwardly in Scheme. I can also implement analogous pattern-matching syntax. 21:10:19 chandler, it can be valuable to provide fixnum operations to the user for performance purposes, even if you also have 32/64 bit computation 21:10:49 (Curiously, I can't implement analogous pattern-matching syntax in C -- does that mean C is ill-fit for `doing bit masks'?) 21:11:09 Riastradh: you'd just bit-twiddle it with shifts. 21:12:05 bgs100 [~ian@unaffiliated/bgs100] has joined #scheme 21:12:06 samth: I think chandler's point is that it's not worth exposing implementation details to the user since the alternative is already efficient (to some definition of efficient) and the compiler can be expected to optimize most other cases. 21:12:51 samth: Why? Using a fixnum operation is either a promise to the compiler that the value fits in whatever the implementation considers to be a fixnum - at which point you might as well choose a modulus that suits the real promise your application is making, rather than the vague and potentially changing "fixnum" - or it is an explicit request for nasal demons, in which case you might as well just provide a `demons->nostril' procedure. 21:12:58 samth, I claim that that's bogus. In order for the use of fixnum operations to be semantically correct, it must be the case that the arithmetic fits into the fixnum modulus. Let's say you prove that by proving that it works for any modulus at least 2^24. In that case, you can tell the compiler what intervals your quantities lie in, in which case the compiler can generate code to avoid bignum arithmetic. 21:13:12 ... or at least that seems to be the consensus, although I don't quite agree with it. 21:13:30 But if you can't prove that your arithmetic is valid modulo 2^24, then it's not valid to use fixnum operations in the first place. 21:14:01 Um. 21:14:06 If I tell SBCL that a given number fits within (signed-byte 24), it will most certainly use a fixnum for the representation, but the statement I am making is a precise statement about the meaning of my program, not a vague statement related only to my external knowledge about how the implementation chooses to represent fixnums. 21:14:13 Fixnum operations in the sense of R6RS are *not* modulo operations. 21:14:15 chandler, I like that -- can we petition the working groups to rename ASSERTION-VIOLATION to DEMONS->NOSTRIL? 21:14:34 first, this isn't a claim about a standard, and therefore there's no need to worry about 2^24 21:14:50 Sure. Let's file that after the request for unbroken exact integer arithmetic. 21:15:17 second, it can certainly be useful to refer to the "fixnum" quantity - it relates to the possible sizes of arrays, for example 21:15:26 samth: It's a claim about a language. The language provided by a single implementation could certainly change over time with respect to the meaning of `fixnum', and it often has. 21:16:06 fradgers- [~fradgers-@5e064cc1.bb.sky.com] has joined #scheme 21:16:07 Riastradh: How do you tell the compiler what intervals your quantities lie in? 21:16:33 It relates to the possible sizes of arrays for hysterical raisins. I doubt an implementation of Scheme which uses a 2^60-bit fixnum can allocate an array that large. 21:16:36 Obfuscate, in Common Lisp? (the (signed-byte 24) ...) is an expression evaluating to the value of ..., provided that ... yields an integer in [-2^24, 2^24). 21:16:39 Er, "I doubt any". 21:17:02 chandler, it's easy to write code where "fixnum" is guaranted to make sense but no range specification makes sense 21:17:28 for example, any system which can allocate arrays of size greater than 2^32 on a 64-bit machine 21:17:29 Are there any Scheme systems in which vectors can have a sparse representation? In that case, the space of valid indices may not be contained in the space of fixnums. 21:17:32 -!- jonrafkind [~jon@crystalis.cs.utah.edu] has quit [Read error: Connection reset by peer] 21:18:16 Riastradh, such a system would be very different from one where vector-length always returns a fixnum, which is the kind of system i'm talking about 21:18:37 Riastradh: Fair enough. I see that as equivalent to a fixnum anyways, so I'll concede. 21:18:37 samth: I'm not sure I understand your statement. 21:19:26 Obfuscate, but it's not equivalent to a fixnum at all. I might instead write (the (signed-byte 64) ...), and there aren't many Lisp systems out there in which the full range of signed, 64-bit integers is represented by fixnums. 21:19:36 jcowan: It's not modular, but it's equally broken. Once again, if the program can sensibly make the statement that some integer fits within what CL calls (unsigned-byte n) where `n' is the fixnum base of the implementation, then it should make that statement. 21:19:42 chandler: (let loop ([x 0]) (if (< x (vector-length v)) (loop (+ x 1)) 'done)) 21:19:48 -!- kuribas [~user@d54C43270.access.telenet.be] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 21:20:18 both < and + can be replaced by fx+ but not by any range-bound with appropriate performance 21:20:51 samth, I don't know of a Scheme system that will generate unboxed-only arithmetic for that. (Some Scheme systems, such as MIT Scheme, will generate unboxed arithmetic, and conditionals for boxed arithmetic.) But I do know of Lisp systems that I'm willing to bet generate unboxed-only arithmetic for that. 21:20:54 It can be replaced by `fx+' if you hold it as invariant that `vector-length' returns a fixnum. This is a silly invariant to encode in anyhting but a compiler. 21:21:05 Riastradh: If that's an unboxed value, I don't see why not, except for failed optimization. 21:21:08 It is a sad state of affairs that no Scheme systems do as well as those Lisp systems. 21:21:39 Riastradh, my claim is that it can be useful to provide fixnum specific operations so that you can use them in such loops 21:21:40 Obfuscate, the point is that writing the actual intervals gives better semantic information than saying `fixnum', and is not semantically incoherent like the concept of `fixnum'. 21:22:00 chandler, i disagree that it's silly to encode that 21:22:13 Instead of saying `fixnum', why not say `array index', then? 21:22:23 index+, index-, &c. 21:22:40 In a system with a sparse representation for vectors, these can still do the right thing. 21:22:47 Mandar [~armand@pha75-21-78-228-186-233.fbx.proxad.net] has joined #scheme 21:22:50 samth: My claim is that your claim is bogus. Not only could an implementation easily deduce the fixnum nature of `x' without this being specified by the user, it would be entirely more useful to have an integral type which represents valid array indices. 21:22:51 That, or, (the array-index ...). 21:22:57 What Riastradh said. 21:24:14 chandler, Riastradh, at this point, we're just disagreeing about whether a language like Scheme should inform users about how it is implemented 21:24:21 Also, before you ask application developers to micro-optimize their programs with these routines, perhaps you would better benefit from investing in making a better compiler. 21:24:44 Riastradh: I mean "bit-vector with a fixed with where arithmetic is defined modulo to 2 ^ width", which is also what I take a fixnum to be. 21:24:52 I'm sick of repeating myself. If you don't understand how it's possible to write correct, meaningfully specified programs that are capable of being implemented efficiently, *please* write some programs using appropriate type declarations in Common Lisp and run them through SBCL. 21:25:09 Riastradh, one potential application of this is to be able to write compilers as source-to-source transformations 21:25:24 -!- choas [~lars@p578F6F42.dip.t-dialin.net] has quit [Quit: leaving] 21:26:03 chandler, i don't see why you think that fixnum is not capable of being meaningfully specified 21:26:12 samth: I would not have a problem with an implementation providing a constant denoting the width of fixnums for the purpose of implementation-specific metaprogramming. 21:26:25 I'd like you to specify it if you think it can! 21:26:54 chandler, http://docs.racket-lang.org/reference/numbers.html?q=fixnum#%28tech._fixnum%29 21:26:55 http://tinyurl.com/37wn7tg 21:27:03 samth, if you're talking about implementing compilers with source-to-source transformations, you're already talking about implementation-land, not language-land. 21:27:14 Riastradh, that's totally false 21:27:21 I'm not sure what this conversation is about anymore. 21:27:40 in Scheme, we have an excellent language that allows users to specify source-to-source rewrites 21:27:46 it's called macros 21:28:39 samth: That's not a specification. In fact, it explicitly says that what (fx+ x y) means differs depending on the platform. 21:29:08 chandler, well, so does (open-input-file "/etc/passwd"). 21:29:16 chandler, it certainly is a specification, it's just a platform dependent specification 21:30:08 if you're unhappy that the denotation of your program depends on the platform it runs on, you're going to be unhappy for a while 21:30:28 samth, what macros are semantically interested in fixnums and not artefacts of the implementation? 21:30:30 Certainly when it comes to arithmetic I'm unhappy about that. 21:30:51 Riastradh, i'm confused by your question 21:30:54 (The latter rules out, for example, a micro-optimization of CASE that turns EQV? into EQ? for those keys on which the two predicates agree.) 21:31:40 Riastradh: Actually, that's less platform-specific than `fx+'. Whether /etc/passwd exists is a different question, but the possibility that a file might not exist is part of the behavior of `open-input-file'. 21:31:54 samth, you said `one potential application of this [fixnum arithmetic, I presume] is to be able to write compilers as source-to-source transformations'; `we have an excellent language that allows users to specify source-to-source rewrites [macros]'. So I would like to know what macros are interested in fixnums. 21:32:29 chandler, well... Your arithmetic is going to be platform-dependent anyway. Example: If you are on an x87 system, you can't, as far as I know, get the hardware to do IEEE 754 arithmetic. 21:32:43 so, in Racket, the implementation of (for ([x (in-range 10)]) ...) can use unsafe-fx+ in the expansion 21:32:52 (Specifically, double-rounding can bite you in the arse.) 21:32:57 samth, why can't the compiler figure that out? 21:33:01 -!- femtooo [~femto@95-89-197-196-dynip.superkabel.de] has quit [Quit: Leaving] 21:33:23 How much effort has been spent by humans reasoning about whether such and such is valid in fixnum arithmetic that could have been spent by a compiler? 21:33:40 Riastradh: That's reason to be unhappy too. 21:33:46 Riastradh, the point is that a macro can express invariants to the compiler via choices about its expansion 21:34:19 samth, why can't the macro express to the compiler that x lies in [0, 10)? Then the compiler has even better information than that x is a fixnum. For example, then the compiler knows that x is not negative. 21:35:21 Riastradh: In fact, I would expect that an implementation which can't provide IEEE 754 should be expected to document where it differs and why. I don't see this as a reason to degrade the standard to permit x87-like bogosity. 21:35:44 It is up to the user to determine whether the variance from 754 will cause a change in the behavior of his or her program. 21:35:47 Hmm...interesting. The documentation that samth pointed to doesn't claim that the floating-point arithmetic follows IEEE 754. 21:36:01 Riastradh, because expressing this information via operations rather than declarations turns out to be be (a) simpler and (b) easier to implement 21:36:04 It only says that inexact reals are represented in the IEEE 754 formats. 21:36:24 Riastradh, that may be an oversight, i'm not sure 21:37:04 chandler, well... To be fair, the x87's arithmetic is almost always better, because it is much more precise, except in the cases where double-rounding happens. 21:37:24 -!- Mandar [~armand@pha75-21-78-228-186-233.fbx.proxad.net] has quit [Ping timeout: 265 seconds] 21:37:51 Riastradh, i'm not sure which sentence you're referring to, but for example, the docs say: "A flonum is used to represent any inexact real number. They correspond to 64-bit IEEE floating-point numbers on all platforms." 21:37:54 IEEE 754 is not a requirement of Scheme. 21:38:13 jcowan, i don't think anyone advocated that 21:38:17 jonrafkind [~jon@crystalis.cs.utah.edu] has joined #scheme 21:38:22 -!- jengle [~jengle@64-252-187-48.adsl.snet.net] has quit [Quit: jengle] 21:38:38 but the consensus on this channel seems to be that Scheme should require unbounded exact integers 21:38:39 So if you take a 64-bit float as an input, and do a bunch of 64-bit arithmetic, and get a 64-bit float as a result, the result is likely to be less accurate to the exact arithmetic than if you took a 64-bit float as an input, converted it to an 80-bit float, did a bunch of 80-bit float arithmetic on the x87, and then truncated it to a 64-bit float at the end. 21:39:14 Riastradh: I'm well aware of that, but few languages actually expose 80-bit floats. Do any implementations of Scheme? 21:39:15 Well, insofar as I'm part of this channel, I don't agree, not that I specifically disagree either. 21:39:19 samth, here's what I'm referring to; `Inexact real numbers are implemented as either single- or double-precision IEEE floating-point numbers.' (Strictly speaking, it doesn't even mention which IEEE standard it's talking about.) 21:39:25 Genosh [~Genosh@155.Red-88-15-69.dynamicIP.rima-tde.net] has joined #scheme 21:39:36 chandler: No. Only one or two expose anything but 64-bit IEEE. 21:39:39 samth: I don't think you're going to convince them otherwise. 21:40:08 chandler, well, C does -- long double. So do some Common Lisp systems, I think. MIT Scheme does only 80-bit arithmetic internally on the i386, but how often it gets truncated depends on how you wrote your program. 21:40:28 Riastradh, "implemented as" doesn't mean "represented as" 21:40:34 -!- samth is now known as samth_away 21:40:40 IIRC there is one that supports 32-bit and 64-bit IEEE, and one that sort of does. 21:40:49 samth, in any case, I expected the Racket documentation to claim that the arithmetic is IEEE 754 arithmetic. 21:40:51 samth: I'm not sure what you meant by "(a) simpler" above, but using operations instead of declarations almost certainly is less informative to the compiler. 21:41:07 How, less informative? 21:41:08 For instance, how do I declare that an operation I've written returns a 32-bit signed integer, so that the compiler may avoid boxing the return value? 21:41:18 Without using type declarations, that is. 21:41:47 You invoke a known operation to coerce the result to 32 bits before returning it. 21:42:03 Or, put it this way: is THE a declaration or an operation? 21:42:54 jcowan: How would a compiler use that coercion to eliminate boxing in the event of a self-call or a mutually recursive call? 21:42:58 Mandar [~armand@pha75-21-78-228-186-233.fbx.proxad.net] has joined #scheme 21:43:11 THE is an operation that can be interpreted as a declaration. DECLARE is a declaration. 21:43:43 (As is DECLAIM - another wonderful Common Lisp bogosity.) 21:43:54 Don't forget PROCLAIM and PROCLARE...er... 21:44:07 PROCLAIM is a function. It really shouldn't ever be used. 21:44:26 If you have irritable fixnum syndrome, talk to your doctor about PROCLARE (tm). 21:47:29 -!- githogori [~githogori@67-207-117-6.static.wiline.com] has quit [Ping timeout: 255 seconds] 21:47:36 -!- bweaver [~user@75-148-111-133-Chattanooga.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 21:47:56 davazp [~user@83.54.167.3] has joined #scheme 21:48:12 Incidentally, I wonder just how much slower PLT's IN-RANGE iterator would be if it didn't use generic arithmetic. 21:48:36 ...er, if it *did* use generic arithmetic, rather. 21:49:07 kar8nga [~kar8nga@78.104.80.166] has joined #scheme 21:50:19 In MIT Scheme, for instance, the effect of replacing (fix:+ ...) by (+ ...) for a loop counter mostly just inserts a type tag test and branch. (The actual consequences are a little more subtle: it has the effect of storing all virtual registers in their homes, so that anything that was loaded from the stack into a register gets flushed; but that was probably going to happen anyway for other reasons, if you were incrementing a loop counter.) 21:50:27 -!- gcartier [~gcartier@modemcable026.84-70-69.static.videotron.ca] has quit [Read error: Connection reset by peer] 21:50:37 Nshag [user@lns-bzn-26-82-254-68-51.adsl.proxad.net] has joined #scheme 21:51:02 In Racket, the byte-code interpreter probably does half a dozen such tests and branches anyway for UNSAFE-FX+. 21:51:24 But that's just a guess -- I don't know how the performance actually differs. 21:53:00 pothos_ [~pothos@111-240-214-188.dynamic.hinet.net] has joined #scheme 21:54:04 -!- REPLeffect [~REPLeffec@69.54.115.254] has quit [Ping timeout: 265 seconds] 21:54:12 -!- pothos [~pothos@111-240-211-11.dynamic.hinet.net] has quit [Read error: Operation timed out] 21:55:18 imran_sr [~imran@75-18-254-4.lightspeed.uncyca.sbcglobal.net] has joined #scheme 21:55:23 -!- pothos_ [~pothos@111-240-214-188.dynamic.hinet.net] has quit [Read error: Connection reset by peer] 21:55:41 pothos [~pothos@111-240-214-188.dynamic.hinet.net] has joined #scheme 21:57:09 SBCL can do unboxed, efficient arithmetic on loop counters even when the loop counter does not fit in a fixnum. :-) 21:57:36 (Provided it knows that the loop bounds will fit in a word-sized integer, that is.) 21:58:54 I still don't see how to do that using operations instead of declarations. 21:59:36 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Remote host closed the connection] 22:01:34 -!- klovett [~klovett@c-67-180-97-38.hsd1.ca.comcast.net] has quit [Quit: klovett] 22:05:31 -!- firecrow8 [~fcrow@69.38.169.34] has quit [Remote host closed the connection] 22:06:42 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 22:07:09 chandler, I know -- I was referring to naive implementations, though, with compilers not smart enough to unbox bounded integer arithmetic (i.e., every Scheme compiler in existence). 22:08:06 Indeed. I was more making the point to samth. 22:09:10 -!- Nshag [user@lns-bzn-26-82-254-68-51.adsl.proxad.net] has quit [Ping timeout: 272 seconds] 22:10:05 REPLeffect [~REPLeffec@69.54.115.254] has joined #scheme 22:10:12 So using fixnum operations is reasonable after all, given that you have a portable way to check the range of a fixnum and see if they meet your needs? 22:11:19 Why check? Why not declare ranges using the information I have available as a programmer and let the implementation pick the most efficient representation? 22:11:31 ...no. Using modular arithmetic is reasonable, and using bounded arithmetic is reasonable. 22:13:05 By "fixnum arithmetic" I mean bounded arithmetic. 22:13:55 Sure -- if the bound is relevant to the semantics of your program. For example, such and such a variable might have a nonnegative integral value bounded by the length of such and such a vector. 22:14:40 But the notion of `fixnum' doesn't enter into it. 22:14:51 -!- REPLeffect [~REPLeffec@69.54.115.254] has quit [Ping timeout: 265 seconds] 22:15:53 Let me take a step back a moment. Can you explain what prompted your message `So using fixnum operations is reasonable after all...'? It wasn't clear to me what part of the discussion motivated that conclusion, but your use of `so' suggested that it was some part of the discussion that did so. 22:16:36 REPLeffect [~REPLeffec@69.54.115.254] has joined #scheme 22:17:19 githogori [~githogori@67-207-117-6.static.wiline.com] has joined #scheme 22:17:29 -!- kar8nga [~kar8nga@78.104.80.166] has quit [Remote host closed the connection] 22:19:47 jengle [~jengle@64-252-187-48.adsl.snet.net] has joined #scheme 22:20:20 I found the discussion difficult to follow, because of the jumping about and the varying assumptions about what fixnums are and what fixnum arithmetic is. 22:21:08 -!- REPLeffect [~REPLeffec@69.54.115.254] has quit [Ping timeout: 265 seconds] 22:22:02 _danb_ [~user@124-149-55-13.dyn.iinet.net.au] has joined #scheme 22:22:09 samth appeared to be saying that providing fixnum arithmetic is useful because it provides modulo artithmetic, which it does not (in the R5RS sense of "fixnum", at least) 22:22:34 To paraphrase Lord Monboddo, you were writing much faster than I am able to read. 22:23:33 samth argued, if I recall correctly, that fixnum arithmetic is useful when the arithmetic is known to be bounded, and consequently can be more efficiently implemented. I don't think he said anything about modular arithmetic. I claim (and I believe chandler agrees) that for that purpose, one should say `bounded arithmetic' in that case, and identify what the bounds are, rather than invoking the word `fixnum'. 22:23:48 Oh, it's the *word* that troubles you? 22:24:55 The word and its meaning -- the R6RS's fixnum arithmetic may be bounded, but the bound is chosen arbitrarily by the implementation, not specified by the program as part of its semantics. 22:25:08 Or is it the claim that greater efficiency is available if the arithmetic is known to be bounded that's the problem. 22:25:14 s/\./? 22:27:07 I note that you seem untroubled by the notion that the range of inexact numbers is chosen by the implementation, as in practice it always is. 22:27:30 It may be the case that the implementation can do signed integer arithmetic bounded in magnitude by 2^24 more efficiently than the general case of integer arithmetic. If so, then when the program says `My arithmetic is signed, limited to integers, and bounded in magnitude by 2^24!', then the implementation can run the program more efficiently. 22:28:01 -!- stis [~stis@1-1-1-39a.veo.vs.bostream.se] has quit [Remote host closed the connection] 22:28:38 OR, it may be the case that the program wants unsigned integer arithmetic bounded in magnitude by 2^48, and it turns out that the implementation can't do that any more efficiently than the general case of integer arithmetic. Fortunately, the implementation can still run the program correctly. 22:29:59 It would be a thoroughly futile exercise to try to represent every real number uniquely. The vast majority of them are not computable in the first place. 22:30:44 Sure, but that's not my point. There is no way on most Scheme systems to request anything but IEEE 64-bit format, even if a different range and precision would suit you better. 22:31:40 schmir [~schmir@p54A90489.dip0.t-ipconnect.de] has joined #scheme 22:31:53 And yet nobody complains. 22:32:16 That's partially because nobody understands or cares about floating-point arithmetic or numerical analysis. 22:32:41 (`Nobody' was rounded from the actual number to fit into the precision of this conversation.) 22:33:35 Nshag [user@lns-bzn-25-82-254-177-74.adsl.proxad.net] has joined #scheme 22:34:11 pnkfelix [~Adium@c-71-225-45-140.hsd1.nj.comcast.net] has joined #scheme 22:35:34 MononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has joined #scheme 22:35:58 Integer arithmetic is well understood, not onerous to implement (as long as you don't need performance fit for serious computation in number theory), and needed by every program in existence. 22:36:43 -!- pnkfelix [~Adium@c-71-225-45-140.hsd1.nj.comcast.net] has quit [Client Quit] 22:37:00 pnkfelix [~Adium@c-71-225-45-140.hsd1.nj.comcast.net] has joined #scheme 22:37:30 REPLeffect [~REPLeffec@69.54.115.254] has joined #scheme 22:37:38 -!- dnm_ [~dnm@static-71-166-174-24.washdc.east.verizon.net] has quit [Ping timeout: 245 seconds] 22:37:55 MonononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has joined #scheme 22:38:06 -!- MonononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has quit [Client Quit] 22:38:26 *jcowan* chuckles. 22:39:05 Fixnum arithmetic, however, is needed by no programs but the internals of language implementations. 22:40:19 -!- MononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has quit [Disconnected by services] 22:40:45 MononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has joined #scheme 22:41:31 -!- MononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has quit [Disconnected by services] 22:42:00 MononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has joined #scheme 22:43:22 -!- REPLeffect [~REPLeffec@69.54.115.254] has quit [Ping timeout: 265 seconds] 22:43:37 -!- MononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has quit [Client Quit] 22:45:32 REPLeffect [~REPLeffec@69.54.115.254] has joined #scheme 22:52:52 And yet most programs use only bounded arithmetic in practice, even unsafe bounded arithmetic. 22:53:33 That is usually because (a) they are written in C or C++, and (b) they are buggy. 22:54:58 You're underestimating the number of programs that use bounded safe specifiable numerical formats as a consequence of being written in Cobol. 22:55:32 Just a moment. 22:55:42 Did you invoke Cobol as justification for a proposed design desicion in Scheme? 22:56:06 No. I merely mention that bounded safe specifiable numeric formats are more common than you think they are. 22:56:32 -!- kephas [~pierre@AStrasbourg-551-1-42-36.w92-148.abo.wanadoo.fr] has quit [Ping timeout: 276 seconds] 22:56:42 In any case, `bounded safe specifiable numeric formats' sounds like bounded arithmetic where the program specifies the bounds. 22:56:55 Not where the implementation specifies the bounds. 22:56:59 Quite. 22:57:28 So this has nothing to do with the notion of fixnums. 22:57:36 So would a bounded-integer implementation parametrized (within a reasonable range) by the bound be a Good Thing? 22:57:38 -!- saac [~saac@unaffiliated/sergio/x-8197433] has quit [Ping timeout: 245 seconds] 22:58:50 Every implementation already is -- the arithmetic is bounded by the size of the machine's memory. It is a parameter because you can put in more RAM if you want. 22:58:56 kephas [~pierre@AStrasbourg-551-1-37-109.w92-148.abo.wanadoo.fr] has joined #scheme 22:59:14 However, scheme48 --maximum-integer=123456789012345678? That would be pretty silly. 22:59:30 saac [~saac@a81-84-164-44.cpe.netcabo.pt] has joined #scheme 22:59:30 -!- saac [~saac@a81-84-164-44.cpe.netcabo.pt] has quit [Changing host] 22:59:31 saac [~saac@unaffiliated/sergio/x-8197433] has joined #scheme 22:59:35 -!- pnkfelix [~Adium@c-71-225-45-140.hsd1.nj.comcast.net] has quit [Quit: Leaving.] 23:00:17 -!- REPLeffect [~REPLeffec@69.54.115.254] has quit [Ping timeout: 265 seconds] 23:00:57 Actually, it's now common for bignums to be bounded by something other than memory, which Scheme should be changed to recognize. 23:01:33 Huh? 23:05:44 Pray elaborate. 23:06:32 -!- davazp [~user@83.54.167.3] has quit [Remote host closed the connection] 23:07:06 jcowan: What range is "reasonable"? 23:07:32 (I'm guessing it's "no larger than the range typically used for fixnums".) 23:07:34 IIRC, there are at least some systems that limit the number of bigits to something less than all of memory so as to allow the bigit count to fit in 32 bits. 23:08:15 Well, a limit of 10^10^10^37 is probably no better than no limit at all. 23:08:28 In 32 bits, or in sizeof(long)*CHAR_BIT bits? 23:08:52 (or sizeof(long)*CHAR_BIT - 2, perhaps) 23:09:35 -!- schmir [~schmir@p54A90489.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 23:10:54 Anyway, it doesn't matter -- it's an implementation restriction just like the available memory. 23:11:08 In libgmp, mp_size, which is the number of bigits, is an int, so you can have at most 2^31 bigits on most systems. 23:11:54 Do most Scheme systems use gmp? 23:12:12 Racket does, I believe. 23:12:26 Yes, but is Racket "most"? :-) 23:12:53 Chicken does. 23:13:12 Chibi doesn't, but its bignum limit is even smaller. 23:13:17 #if defined (_CRAY) && ! defined (_CRAYMPP) / typedef int mp_size_t; / #else / typedef long int mp_size_t / #endif 23:13:20 Hmmmmmmmmm. 23:13:27 How many Chicken users run it on Crays? 23:14:03 REPLeffect [~REPLeffec@69.54.115.254] has joined #scheme 23:14:49 Does MIT Scheme have a limit on the size of bignums that is smaller than the heap limit? 23:15:11 I'm fairly confident Gambit (another non-GMP implementation) does. 23:16:15 On 32-bit systems? No. On 64-bit systems, maybe -- I don't remember the details of the representation, which I frobbed recently, but not enough to have burned it into my head. 23:16:24 Aha! 23:16:27 klovett [~klovett@c-67-180-97-38.hsd1.ca.comcast.net] has joined #scheme 23:16:56 The difference between an integer limit of 2^29 bits and a limit of 2^2^29 bits is, well, astronomical. In the latter case, the limit is large enough that users who wish to perform cacluations on values of this magnitude may wish to find a completely different data representation anyway. 23:17:05 `This limit guarantees that the number of bits in a bignum (in ones- or two's-complement) fits in a long. Practically speaking, we won't reach this limit even on a 32-bit machine because the heap can hold at most 2^26 bytes, and thus 2^24 digits -- which is already less than this value, a little under 2^25. The same applies to 64-bit machines; it doesn't cease to apply until 128-bit machines, but we're not going to worry about those.' 23:17:19 #define BIGNUM_LENGTH_MAX ((BIGNUM_RADIX / BIGNUM_DIGIT_LENGTH) - BIGNUM_DIGIT_LENGTH) 23:18:39 -!- REPLeffect [~REPLeffec@69.54.115.254] has quit [Ping timeout: 265 seconds] 23:18:43 So, on 32-bit systems? No. On 64-bit systems? No. On 128-bit systems? Yes, but why don't you give up paying for AS/400 support from IBM and just use commodity hardware? 23:19:53 (Not that you can allocate that much memory on an AS/400 system anyway -- if I recall correctly, the 128 bits of address space reserves 64 bits for a process identifier (or some other address space identifier, such as a disk) and 64 bits for the actual address.) 23:19:55 As far as I'm aware, there's no 128-bit C compiler for the AS/400, and the virtual instruction set isn't documented publicly. 23:20:19 -!- jcowan [c6b912cf@gateway/web/freenode/ip.198.185.18.207] has quit [Ping timeout: 265 seconds] 23:22:16 -!- klovett [~klovett@c-67-180-97-38.hsd1.ca.comcast.net] has quit [Quit: klovett] 23:24:26 jcowan [~John@98.14.172.204] has joined #scheme 23:27:31 chibi's limit is 2^32 32-bit integers on a 32-bit machine, and 2^64 64-bit integers on a 64-bit machine 23:28:10 Digits? 23:28:29 yes 23:29:22 This discussion calls to mind http://jwz.livejournal.com/854482.html . 23:29:38 -!- drdo [~user@98.192.108.93.rev.vodafone.pt] has quit [Ping timeout: 255 seconds] 23:31:36 REPLeffect [~REPLeffec@69.54.115.254] has joined #scheme 23:32:30 chandler: didn't the ILE C compiler support 128 bits on the iseries? 23:33:50 Did it? My knowledge of the AS/400 is cursory at best. 23:34:33 I think the default size of pointers was 128 bit, and definitely there was a pragma() to change it. 23:34:51 But... I don't know if it does some conversion internally or not. 23:34:56 Ah, you're right about that. 23:35:04 Very interesting. 23:36:06 foof: Sorry about the ReBallot snafu, but I do think separate ballots for separate elections are best, even if the issues are the same. 23:37:35 -!- githogori [~githogori@67-207-117-6.static.wiline.com] has quit [Ping timeout: 255 seconds] 23:38:30 So, the Scheme systems I've found that use GMP are Racket and Guile. Are there others I'm missing? 23:39:00 (In no particular order) MIT Scheme, Scheme48, Gambit, Gauche, Chibi, Larceny, and Chez all use their own implementations. 23:39:22 Oh, Ikarus uses GMP, and I'd be willing to bet that some other R6RS implementations do too. 23:40:07 kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has joined #scheme 23:40:35 There are R6RS implementations? 23:40:59 Yes; I'm thinking of Ypsilon and Mosh here. 23:42:30 Ypsilon has its own implementation. Mosh uses GMP. 23:42:36 There are R6RS implementations in the same sense that there are R5RS ones. 23:42:55 Oh, and Chicken uses GMP if you enable it. 23:43:08 That is, Chicken uses GMP or nothing. 23:43:40 Unless I'm missing something obvious, it doesn't seem to be the case that most Scheme implementations that provide effectively unbounded integer arithmetic use GMP. 23:43:52 I cited it only as an example. 23:44:47 What prompted the survey of bignum libraries and the mention of GMP? I forgot. 23:44:51 STKlos seems to use GMP too. 23:44:53 My own curiosity, actually. 23:45:06 Sorry; I'm off on a tangent here. 23:45:29 Also, I pointed out that some implementations set limits on bignums other than mere memory size. 23:46:35 I considered switching MIT Scheme to use GMP, and spent a few hours on it, but ended up throwing it out. I don't remember why, precisely, but there was something technical. 23:46:59 saccade [~saccade@209-6-54-113.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 23:47:50 One problem is that not all C compilers can compile GMP, or even report that they cannot. 23:48:59 I concluded that memory allocation probably would not be an issue, because the mpn_* routines don't ever store newly allocated pointers anywhere interesting, so it is OK to back out of an allocation failure with longjmp, do a GC, and restart the operation. 23:49:26 "Most problems with compiling GMP these days are due to problems not in GMP, but with the compiler. In the past, system compilers caused the most trouble, but in the last years, gcc has gradually caused more and more trouble. On these pages we don't list compiler problems, just problems with the GMP code itself. To save you some time, we suggest that you cut any compiler error message and paste it into your favourite web search engine before you report proble 23:49:26 ms to the GMP bug report list." 23:50:01 Ah. 23:50:03 Jafet [~Jafet@unaffiliated/jafet] has joined #scheme 23:50:06 "Gcc 4.3.2 miscompiles GMP on 64-bit machines; please use a different gcc version (e.g., gcc 4.3.1 and gcc 4.3.3 both work properly). We have not been able to find any workaround for this gcc bug. Unfortunately, Debian 5.0 has decided to stay with this trouble gcc version, resulting in that many users strike this bug.)" 23:50:36 -!- elderK [~k@pdpc/supporter/active/elderk] has quit [Ping timeout: 240 seconds] 23:50:58 And of course we were talking about bignums at all because I put my foot in it with regard to the proposed WG2 time library. 23:57:13 -!- jengle [~jengle@64-252-187-48.adsl.snet.net] has quit [Quit: jengle] 23:57:56 jcowan: For separate elections I could go either way, but this was just an extension. 23:59:42 The bigger problem was I hadn't yet setup machinery to handle foo/bar option variants where the "foo" preference wasn't included.