Re: [Chicken-users] [recommendation] Run interactive commands inside a Vim buffer
Yi Dai wrote: I just came across a cool kit that lets you run interactive commands inside a Vim buffer. It is called Conque! This is great, much better than the VimSh featured on our own wiki http://wiki.call-cc.org/vim I will update the wiki shortly, as soon as I set up a few macros for it. I have only tried it for 5 minutes, but here are a few reasons why Conque is way better than VimSh: - it detects on its own when there is new output to show; - insert mode jumps to the bottom of the buffer; - it correctly translates arrows and other special keys; - it interprets ansi color and other control sequences; - it even handles curses programs! (somewhat) Thank you for this gem Tobia ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Possible numbers bug
On Sun, May 29, 2011 at 11:39:31PM +0200, Peter Bex wrote: On Fri, May 27, 2011 at 10:58:04AM +0200, Dominic Pearson wrote: Hello folks, I am trying to compute the sum i = 0 to n where n = 1000 of n^n, but chicken seems to return the incorrect answer. http://paste.call-cc.org/paste?id=e0884580a684d1220f3dedb819f63201b6f5eb1a Racket and scheme48 both seem to give different answers too. I figured out where it goes wrong. expt calls the base Chicken expt and if that returns a fixnum, this result is used (if it's a flonum it might've overflowed and is inexact anyway so it will use a different path). This algorithm is sound. No, it's not. The pow() function in C doesn't set errno when it drops some digits so there's apparently no way to detect this. I've ripped out the expt code and it now uses the same path for bignums and fixnums. This has been released as version 2.5 of the numbers egg. Thanks for reporting this! Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Possible numbers bug
Hi guys,it’s not strictly about Chicken, but a quick note about 0^0 is in order.Dominic Pearson wrote:Hello folks,I am trying to compute the sum i = 0 to n where n = 1000 of n^nPanos Stergiotis wrote:Total[Table[i^i, {i, 1, 1000}]] + 1 yields[...]The + 1 is because 0^0 is not defined in mathematicaIt’s more than that, 0^0 is not defined in Maths.Simply put: lim(0^x) for x→0 = 0 lim(x^0) for x→0 = 1Therefore 0^0 has more than one solution -or- is undefined.Graphical explanation: if you plot the surface z = x^y, you will see that it approaches the origin both with value constantly 1from one direction (along the x axis, where y = 0) andwith value constantly 0 from the other (along the y axis, where x = 0). Therefore, at the very origin, both 0 and 1 are solutions! Moreover, all numbers between 0 and 1 seem to be solutions too, looking at the graph. (Other numbers would be too, if you plotted the other quadrants of the surface… some of which are imaginary :-)CheersTobia___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Possible numbers bug
another thing:
the derivation of x^x gives x^x*(1+Log(x)) it has thus a critical value at
x_crit = Exp[-1]
the second derivative is x^(-1 + x) + x^x (1 + Log(x))^2 which is about
1.8816 at x_crit so it is a minima.
thinking of x^x as a continous function, 0^0 is thus clearly 1 ;-)
(see the silly plot in the attachement)
cu
On Wednesday 01 June 2011 20:56:52 Tobia Conforto wrote:
Hi guys,
it’s not strictly about Chicken, but a quick note about 0^0 is in order.
Dominic Pearson wrote:
Hello folks,
I am trying to compute the sum i = 0 to n where n = 1000 of n^n
Panos Stergiotis wrote:
Total[Table[i^i, {i, 1, 1000}]] + 1 yields
[...]
The + 1 is because 0^0 is not defined in mathematica
It’s more than that, 0^0 is not defined in Maths.
Simply put:
lim(0^x) for x→0 = 0
lim(x^0) for x→0 = 1
Therefore 0^0 has more than one solution -or- is undefined.
Graphical explanation: if you plot the surface z = x^y, you will see that
it approaches the origin both with value constantly 1 from one direction
(along the x axis, where y = 0) and with value constantly 0 from the other
(along the y axis, where x = 0). Therefore, at the very origin, both 0 and
1 are solutions! Moreover, all numbers between 0 and 1 seem to be
solutions too, looking at the graph. (Other numbers would be too, if you
plotted the other quadrants of the surface… some of which are imaginary
:-)
Cheers
Tobia
xx.pdf
Description: Adobe PDF document
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] posix strptime
Hi all, I'm trying to convert a time string to seconds and back and I'm having a problem using string-time, local-time-seconds, and seconds-local-time in unit posix: CHICKEN (c)2008-2011 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 4.7.0 openbsd-unix-gnu-x86-64 [ 64bit manyargs dload ptables ] compiled 2011-06-01 on kili.jsbsystems.com (OpenBSD) #;1 (use posix) ; loading library posix ... #;2 (string-time 20110601235959 %Y%m%d%H%M%S) #(59 59 23 1 5 111 0 0 #f 0) #;3 (seconds-local-time (local-time-seconds (list-vector (list 59 59 23 1 5 111 6 31 #f 0 #(59 59 0 2 5 111 4 152 #t 14400) ; tz info set, and off by an hour #;4 (local-timezone-abbreviation) EDT string-time seems to be ignoring the local timezone, but local-time-seconds and seconds-local-time are not. This prevents me from converting a string time to seconds and back. I get back a different answer than I input. This bug cropped up when something set the dstflag and timezone values in the vector and it seems that strptime isn't populating them, if they're not specified in the format string. I haven't figured out what the something was, but I was suddenly getting results from string-time for 2003010212 having dstflag=#t and timezone=14400, which is clearly wrong for the middle of the winter (for me, anyway). Am I just dealing with a deficiency in strptime? TIA, Dave ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
