From nickle at po8.org Sun Feb 12 17:37:07 2006 From: nickle at po8.org (nickle@po8.org) Date: Sun, 12 Feb 2006 17:37:07 -0800 Subject: [Nickle] User trap revisited---setjmp() at top level Message-ID: <20060213022207.5C95C130027@keithp.com> I just got bit by an old user trap again, and wanted to vent. Also, I'm hoping there's an easy fix. If you capture a continuation via setjmp() at top level in Nickle, when you longjmp() through it execution continues in the thread that captured the continuation. Unfortunately, in the current implementation each top-level statement is executed in its own thread. This is confusing, to say the least. I think it should be possible to make setjmp() throw an exception when called at top level, no? And isn't this what is wanted, given that it's going to behave in such a surprising fashion? Bart From keithp at keithp.com Sun Feb 12 19:02:27 2006 From: keithp at keithp.com (Keith Packard) Date: Sun, 12 Feb 2006 19:02:27 -0800 Subject: [Nickle] User trap revisited---setjmp() at top level In-Reply-To: <20060213022207.5C95C130027@keithp.com> References: <20060213022207.5C95C130027@keithp.com> Message-ID: <1139799748.4183.80.camel@evo.keithp.com> On Sun, 2006-02-12 at 17:37 -0800, nickle at po8.org wrote: > I think it should be possible to make setjmp() throw an > exception when called at top level, no? And isn't this what > is wanted, given that it's going to behave in such a > surprising fashion? that would be trivial, but not exactly a complete fix, any call sequence which terminates in setjmp and then exits back out the top has precisely the same issue. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/nickle/attachments/20060212/045aa57b/attachment.pgp From bart at po8.org Tue Feb 14 14:41:30 2006 From: bart at po8.org (Bart Massey) Date: Tue, 14 Feb 2006 14:41:30 -0800 Subject: [Nickle] User trap revisited---setjmp() at top level In-Reply-To: <1139799748.4183.80.camel@evo.keithp.com> References: <20060213022207.5C95C130027@keithp.com> <1139799748.4183.80.camel@evo.keithp.com> Message-ID: <20060214224144.62B1E13002C@keithp.com> Good point. I'm now extra-confused as to what I even want. But something needs to be done. I just noticed that putting a namespace{} declaration around code potentially changes its meaning, since the namespace encloses its statements in a block. Bleah. Bart In message <1139799748.4183.80.camel at evo.keithp.com> you wrote: > > --===============1272567500== > Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XkVDsgPXy4PdMLtqiEAO" > > > --=-XkVDsgPXy4PdMLtqiEAO > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > On Sun, 2006-02-12 at 17:37 -0800, nickle at po8.org wrote: > > > I think it should be possible to make setjmp() throw an > > exception when called at top level, no? And isn't this what > > is wanted, given that it's going to behave in such a > > surprising fashion? > > that would be trivial, but not exactly a complete fix, any call sequence > which terminates in setjmp and then exits back out the top has precisely > the same issue. > =20 > > --=20 > keith.packard at intel.com > > --=-XkVDsgPXy4PdMLtqiEAO > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > > iD8DBQBD7/bDQp8BWwlsTdMRAh3wAJ9vhnGDZns6nd3oENoRpkBAdT6nagCfcO7W > uywdsb0dhhXKG8VhsepngcE= > =oluA > -----END PGP SIGNATURE----- > > --=-XkVDsgPXy4PdMLtqiEAO-- > > --===============1272567500== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > Nickle mailing list > Nickle at nickle.org > http://nickle.org/mailman/listinfo/nickle > > --===============1272567500==-- From michel.salim at gmail.com Sat Feb 18 21:33:54 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 19 Feb 2006 00:33:54 -0500 Subject: [Nickle] Mutual tail-recursion Message-ID: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> Hi, I just learned of Nickle's existence earlier today (thanks to a reference by Lambda-the-Ultimate user po8, real identity unknown, though he seems to be involved here), and I'm finding it quite interesting (being able to print function definitions is really nice for prototyping and learning APIs) As per my standard practice when trying out languages with functional programming features, I subjected Nickle to recursively testing evenness: /* there's probably a better way to forward-declare a function */ oddp = bool func(int n) { return false;}; evenp = bool func (int n) { if (0==n) return true; else return oddp(n-1); }; oddp = bool func (int n) { if (0==n) return false; else return evenp(n-1); }; Doing this in GCC, if I remember correctly, results in a stack overflow at n ~= 140000, unless sibling-call optimization is turned on. Nickle surprisingly managed to compute the result of testing n = 10 million, though the memory usage gets disquieting at that point. A byproduct of the call "stack" actually being heap-allocated to support continuations? My questions are, then: - Is tail optimization of mutually-recursive functions planned? - Garbage collecting: after doing evenp(10000000) nickle was consuming 67.3% of 1.4GB of RAM. after about 10 minutes this has only gone down to 67.0% .. should it be holding on to the memory for that long? Is there a way to request a collection? Also, I'll probably propose Nickle for submission to Fedora Extras (surprisingly, the original RPM spec was written by none other than Mike Harris, Red Hat's X developer). Is there any runtime dependency on the header files? I'm currently splitting the header files to a -devel package. PS the turtle/snowflake.5c and menace2.5c have their executable bits incorrectly set. Best regards, -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From bart at po8.org Sat Feb 18 22:40:50 2006 From: bart at po8.org (Bart Massey) Date: Sat, 18 Feb 2006 22:40:50 -0800 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> Message-ID: <20060219064058.C58D213001F@keithp.com> In message <883cfe6d0602182133j4c18f9a3s at mail.gmail.com> you wrote: > I just learned of Nickle's existence earlier today (thanks to a > reference by Lambda-the-Ultimate user po8, real identity unknown, > though he seems to be involved here) That's me :-). Sorry for the whole 'nym thing; always hard to know whether to just use a real name in these situations. After all, I might say something even more stupid than usual. > and I'm finding it quite > interesting (being able to print function definitions is really nice > for prototyping and learning APIs) Glad you like it! > As per my standard practice when trying out languages with functional > programming features, I subjected Nickle to recursively testing > evenness: > > /* there's probably a better way to forward-declare a function */ > oddp = bool func(int n) { return false;}; Just bool oddp(int); will work. :-) > evenp = bool func (int n) { if (0==n) return true; else return oddp(n-1); }; > oddp = bool func (int n) { if (0==n) return false; else return evenp(n-1); }; bool evenp(int n) { if (0==n) return true; else return oddp(n-1);} bool oddp(int n) { if (0==n) return false; else return evenp(n-1);} > Doing this in GCC, if I remember correctly, results in a stack > overflow at n ~= 140000, unless sibling-call optimization is turned > on. Nickle surprisingly managed to compute the result of testing n = > 10 million, though the memory usage gets disquieting at that point. A > byproduct of the call "stack" actually being heap-allocated to support > continuations? Call frames are indeed heap-allocated to support closures/continuations, but this sounds more like a bug---we (try to) do full tail-call. I can't entirely reproduce the bug, though. With n=1e7 I get a response in maybe 20 seconds and end up with about 20M of memory used. Further runs at that level don't increase the memory, so it doesn't seem to be a straight leak. > My questions are, then: > - Is tail optimization of mutually-recursive functions planned? Already done. Tail-call analysis is fun. :-) > - Garbage collecting: after doing evenp(10000000) nickle was consuming > 67.3% of 1.4GB of RAM. after about 10 minutes this has only gone down > to 67.0% .. should it be holding on to the memory for that long? Is > there a way to request a collection? You can invoke the garbage collector with Debug::collect(), although this is highly non-intuitive. :-) > Also, I'll probably propose Nickle for submission to Fedora Extras > (surprisingly, the original RPM spec was written by none other than > Mike Harris, Red Hat's X developer). Yeah, since Keithp is involved, we get a lot of those. :-) > Is there any runtime dependency > on the header files? I'm currently splitting the header files to a > -devel package. I'm not sure the header files are good for anything, actually... > PS the turtle/snowflake.5c and menace2.5c have their executable bits > incorrectly set. Ahh. I'm guessing you're installing from the latest "release" tarball---we discourage this. :-( Build from CVS top of tree and let us know if you still have that bug on your system. :-) For a 20-year-old language, we sure have an immature release process. Our apologies. We're moving Nickle to GIT in the *very* near term. Once I do that, we'll check all the permissions and fix them. Thanks for the feedback, and please continue to let us know as you find bugs or misfeatures! Bart Massey bart at cs.pdx.edu From keithp at keithp.com Sun Feb 19 14:06:39 2006 From: keithp at keithp.com (Keith Packard) Date: Sun, 19 Feb 2006 14:06:39 -0800 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> Message-ID: <1140386799.4341.324.camel@evo.keithp.com> On Sun, 2006-02-19 at 00:33 -0500, Michel Salim wrote: > My questions are, then: > - Is tail optimization of mutually-recursive functions planned? Planned and implemented; you were hit by run-time typechecking required by the use of poly values for oddp and evenp and the declared return types for their associated functions. If you use the form suggested by bart, or if you declare matching types for oddp and evenp, you get the memory usage pattern shown by bart. > Also, I'll probably propose Nickle for submission to Fedora Extras > (surprisingly, the original RPM spec was written by none other than > Mike Harris, Red Hat's X developer). Is there any runtime dependency > on the header files? I'm currently splitting the header files to a > -devel package. Sensible. These are used by external FFI libraries, like the one for the cairo graphics library, and shouldn't ever be needed by 'normal' users of nickle. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/nickle/attachments/20060219/1e17d50b/attachment.pgp From michel.salim at gmail.com Mon Feb 20 05:37:06 2006 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 20 Feb 2006 08:37:06 -0500 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <1140386799.4341.324.camel@evo.keithp.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> <1140386799.4341.324.camel@evo.keithp.com> Message-ID: <883cfe6d0602200537r25a003a0l@mail.gmail.com> On 19/02/06, Keith Packard wrote: > On Sun, 2006-02-19 at 00:33 -0500, Michel Salim wrote: > > > My questions are, then: > > - Is tail optimization of mutually-recursive functions planned? > > Planned and implemented; you were hit by run-time typechecking required > by the use of poly values for oddp and evenp and the declared return > types for their associated functions. If you use the form suggested by > bart, or if you declare matching types for oddp and evenp, you get the > memory usage pattern shown by bart. Ah, OK. That's rather interesting - so an anonymous function declaration bound to a variable (oddp = bool func (int n) {return false;}; ) is not *exactly* identical as a type signature declaration (bool oddp(int); ) ? It seems that the run-time typechecking could be optimized (though it's probably not worth the trouble): since in this case evenp and oddp are called recursively every other function call, if the virtual machine could detect that this is the case, then perhaps the type checking could be deferred to the innermost evenp and oddp call? (this gets more complicated in case there are >2 functions that call each other, but for a function f, for every pair of (f, g_n) only the innermost f needs to typecheck the return value of g_n. > > > Also, I'll probably propose Nickle for submission to Fedora Extras > > (surprisingly, the original RPM spec was written by none other than > > Mike Harris, Red Hat's X developer). Is there any runtime dependency > > on the header files? I'm currently splitting the header files to a > > -devel package. > > Sensible. These are used by external FFI libraries, like the one for the > cairo graphics library, and shouldn't ever be needed by 'normal' users > of nickle. > Thanks. I'll make not of this in the .spec file. -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From michel.salim at gmail.com Mon Feb 20 05:41:57 2006 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 20 Feb 2006 08:41:57 -0500 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <43f812f5.4d33e767.1967.6fbbSMTPIN_ADDED@mx.gmail.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> <43f812f5.4d33e767.1967.6fbbSMTPIN_ADDED@mx.gmail.com> Message-ID: <883cfe6d0602200541k1eb503e5n@mail.gmail.com> On 19/02/06, Bart Massey wrote: > > My questions are, then: > > - Is tail optimization of mutually-recursive functions planned? > > Already done. Tail-call analysis is fun. :-) > Neat. The only pie-in-the-sky feature that remains for me to ask is, thus, higher-order functions.. Can a function return a function, and be passed functions as arguments? > > - Garbage collecting: after doing evenp(10000000) nickle was consuming > > 67.3% of 1.4GB of RAM. after about 10 minutes this has only gone down > > to 67.0% .. should it be holding on to the memory for that long? Is > > there a way to request a collection? > > You can invoke the garbage collector with Debug::collect(), > although this is highly non-intuitive. :-) > Ah. Handy, thanks. > We're moving Nickle to GIT in the *very* near term. Once I > do that, we'll check all the permissions and fix them. Looking forward to it. GIT (with Cogito) seems like a really pain-free way to do version control. Many thanks, -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From keithp at keithp.com Mon Feb 20 09:36:12 2006 From: keithp at keithp.com (Keith Packard) Date: Mon, 20 Feb 2006 09:36:12 -0800 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <883cfe6d0602200537r25a003a0l@mail.gmail.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> <1140386799.4341.324.camel@evo.keithp.com> <883cfe6d0602200537r25a003a0l@mail.gmail.com> Message-ID: <1140456973.16926.30.camel@evo.keithp.com> On Mon, 2006-02-20 at 08:37 -0500, Michel Salim wrote: > Ah, OK. That's rather interesting - so an anonymous function > declaration bound to a variable (oddp = bool func (int n) {return > false;}; ) is not *exactly* identical as a type signature declaration > (bool oddp(int); ) ? What you have done is effectively: > poly oddp = bool func (int n) { return false; }; We allow variable declarations at the top level to leave off the type declaration for convenience. If, instead, you had done: > bool(int n) oddp = bool func (int n) { return false; }; then 'oddp' would have had the precise type needed to skip the typechecking on the recursive returns. The short hand notation: > bool oddp (int n) { return false; } is just syntactic sugar for the second form. > It seems that the run-time typechecking could be optimized (though > it's probably not worth the trouble): since in this case evenp and > oddp are called recursively every other function call, if the virtual > machine could detect that this is the case, then perhaps the type > checking could be deferred to the innermost evenp and oddp call? (this > gets more complicated in case there are >2 functions that call each > other, but for a function f, for every pair of (f, g_n) only the > innermost f needs to typecheck the return value of g_n. There's nothing preventing you from reassigning a new value to 'oddp' or 'evenp' after the functions have been compiled, so the only opportunity for optimization is to check the return type for the dynamically bound values and conditionally tail-call. With the proper types declared at compile time, there isn't any way you can assign a function that would have the wrong type afterwards. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/nickle/attachments/20060220/1d4deecd/attachment.pgp From keithp at keithp.com Mon Feb 20 09:37:24 2006 From: keithp at keithp.com (Keith Packard) Date: Mon, 20 Feb 2006 09:37:24 -0800 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <883cfe6d0602200541k1eb503e5n@mail.gmail.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> <43f812f5.4d33e767.1967.6fbbSMTPIN_ADDED@mx.gmail.com> <883cfe6d0602200541k1eb503e5n@mail.gmail.com> Message-ID: <1140457044.16926.32.camel@evo.keithp.com> On Mon, 2006-02-20 at 08:41 -0500, Michel Salim wrote: > Neat. The only pie-in-the-sky feature that remains for me to ask is, > thus, higher-order functions.. Can a function return a function, and > be passed functions as arguments? Functions are first-class objects, so of course this works. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/nickle/attachments/20060220/6a9c930f/attachment.pgp From michel.salim at gmail.com Tue Feb 21 15:16:27 2006 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 21 Feb 2006 18:16:27 -0500 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <1140457044.16926.32.camel@evo.keithp.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> <43f812f5.4d33e767.1967.6fbbSMTPIN_ADDED@mx.gmail.com> <883cfe6d0602200541k1eb503e5n@mail.gmail.com> <1140457044.16926.32.camel@evo.keithp.com> Message-ID: <883cfe6d0602211516t79d8c052o14768315305fc22e@mail.gmail.com> On 2/20/06, Keith Packard wrote: > On Mon, 2006-02-20 at 08:41 -0500, Michel Salim wrote: > > > Neat. The only pie-in-the-sky feature that remains for me to ask is, > > thus, higher-order functions.. Can a function return a function, and > > be passed functions as arguments? > > Functions are first-class objects, so of course this works. > Apologies, this is definitely a case of RTFM. So right now the only snag with using higher-order functions is that its type signature is either very tightly specified (e.g. bool(int,int) ) or loosely-specified (e.g. bool(poly,poly) ), without a possibility of saying bool(a,a) that parametric polymorphism gives? Looking forward to that feature making it in. It's time to start reading the technical specifications.. -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From keithp at keithp.com Tue Feb 21 15:35:27 2006 From: keithp at keithp.com (Keith Packard) Date: Tue, 21 Feb 2006 15:35:27 -0800 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <883cfe6d0602211516t79d8c052o14768315305fc22e@mail.gmail.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> <43f812f5.4d33e767.1967.6fbbSMTPIN_ADDED@mx.gmail.com> <883cfe6d0602200541k1eb503e5n@mail.gmail.com> <1140457044.16926.32.camel@evo.keithp.com> <883cfe6d0602211516t79d8c052o14768315305fc22e@mail.gmail.com> Message-ID: <1140564928.16926.159.camel@evo.keithp.com> On Tue, 2006-02-21 at 18:16 -0500, Michel Salim wrote: > Apologies, this is definitely a case of RTFM. So right now the only > snag with using higher-order functions is that its type signature is > either very tightly specified (e.g. bool(int,int) ) or > loosely-specified (e.g. bool(poly,poly) ), without a possibility of > saying bool(a,a) that parametric polymorphism gives? Right, we're stuck figuring out how to define and implement parametric polymorphism, so all we've got right now is subclass polymorphism. -- keith.packard at intel.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/nickle/attachments/20060221/4c9967a6/attachment.pgp From bart at po8.org Tue Feb 21 15:41:25 2006 From: bart at po8.org (Bart Massey) Date: Tue, 21 Feb 2006 15:41:25 -0800 Subject: [Nickle] Mutual tail-recursion In-Reply-To: <883cfe6d0602211516t79d8c052o14768315305fc22e@mail.gmail.com> References: <883cfe6d0602182133j4c18f9a3s@mail.gmail.com> <43f812f5.4d33e767.1967.6fbbSMTPIN_ADDED@mx.gmail.com> <883cfe6d0602200541k1eb503e5n@mail.gmail.com> <1140457044.16926.32.camel@evo.keithp.com> <883cfe6d0602211516t79d8c052o14768315305fc22e@mail.gmail.com> Message-ID: <20060221234135.F24C213003D@keithp.com> In message <883cfe6d0602211516t79d8c052o14768315305fc22e at mail.gmail.com> you wrote: > So right now the only snag with using higher-order > functions is that its type signature is either very > tightly specified (e.g. bool(int,int) ) or > loosely-specified (e.g. bool(poly,poly) ), without a > possibility of saying bool(a,a) that parametric > polymorphism gives? Yes, this is a definite hole in the language. On the other hand, we do at least support a (IMHO) nice notion of subtyping: you can say bool(real,int) and then pass two ints without any explicit or implicit conversions or coercions. And of course, it's not just functions: the subtyping rules extend in sensible (?) ways throughout the language. It's still not a substitute for real parametric/template polymorphism, though. :-) Bart From michel.salim at gmail.com Mon Feb 27 19:47:19 2006 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 27 Feb 2006 22:47:19 -0500 Subject: [Nickle] BigInteger bug Message-ID: <883cfe6d0602271947k69cdcecet424f216146320063@mail.gmail.com> So I do realize that the code from CVS HEAD is canonical, but it's currently in a non-building state.. I thus can't verify whether this works in recent CVS builds or not. As seen from the code below, it seems that the conversion from integer to big integer is not done at the right spot, and given two sufficiently large numbers the sum is negative. > print fib int fib (int n) { return fibh (n, 1, 1); } > print fibh int fibh (int n, int a, int b) { if (0 == n) return a; else return fibh (n - 1, b, a + b); } > fib(42) 433494437 > fib(43) 701408733 > 4334944370 4334944370 > 4334944370 + 701408733 5036353103 > 433494437 + 701408733 -1012580478 -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/ From bart at po8.org Mon Feb 27 23:19:32 2006 From: bart at po8.org (Bart Massey) Date: Mon, 27 Feb 2006 23:19:32 -0800 Subject: [Nickle] BigInteger bug In-Reply-To: <883cfe6d0602271947k69cdcecet424f216146320063@mail.gmail.com> References: <883cfe6d0602271947k69cdcecet424f216146320063@mail.gmail.com> Message-ID: <20060228071937.5429013001E@keithp.com> Interesting bug report! This is one of the uglier Nickle bugs in quite a long time. Unfortunately, I can't reproduce the bug from CVS head. Also, I tried building CVS head from scratch on my home Linux box, and it seems to build fine. I'm afraid we'll need a bit more information so we can track down and solve your problem. Exactly what version of the Nickle source were you using, obtained from where? What operating system? What CPU? What specific build problem did you have? Can you supply a script that will reproduce the bug reliably? In particular, is the invocation of fib() necessary, or does just typing in the last sum fail (I'd expect the latter)? Let us know and we'll track this down and fix it for you. Bart P.S.---BTW, it's not terribly relevant and I'm sure you know this, but the normal way to code what you were doing would be to use nested functions to hide the utility function fibh()... int fib (int n) { int fibh (int n, int a, int b) { if (0 == n) return a; else return fibh (n - 1, b, a + b); } return fibh (n, 1, 1); } In message <883cfe6d0602271947k69cdcecet424f216146320063 at mail.gmail.com> you wrote: > So I do realize that the code from CVS HEAD is canonical, but it's > currently in a non-building state.. I thus can't verify whether this > works in recent CVS builds or not. > > As seen from the code below, it seems that the conversion from integer > to big integer is not done at the right spot, and given two > sufficiently large numbers the sum is negative. > > > print fib > int fib (int n) > { > return fibh (n, 1, 1); > } > > print fibh > int fibh (int n, int a, int b) > { > if (0 == n) > return a; > else > return fibh (n - 1, b, a + b); > } > > fib(42) > 433494437 > > fib(43) > 701408733 > > 4334944370 > 4334944370 > > 4334944370 + 701408733 > 5036353103 > > 433494437 + 701408733 > -1012580478 > > > -- > Michel Salim > http://www.cs.indiana.edu/~msalim > http://the-dubois-papers.blogspot.com/ > _______________________________________________ > Nickle mailing list > Nickle at nickle.org > http://nickle.org/mailman/listinfo/nickle