cmucl-ticket May 2007

cmucl-ticket@common-lisp.net

1 participants
3 discussions

[cmucl-ticket] [cmucl] #1: prin1 and ~E produce different outputs.
by cmucl 03 Oct '07

03 Oct '07

#1: prin1 and ~E produce different outputs. ------------------------+--------------------------------------------------- Reporter: anonymous | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: component1 | Version: Keywords: printing | ------------------------+--------------------------------------------------- (let ((x (random 1d-3))) (values (prin1-to-string x) (format nil "~E" x))) will produce different significant digits. I think the problem is in ~E which calls lisp::scale-exponent to scale the number between 0.1 and 1. I think we could just call flonum-to-digits which will give us the digits and the exponent. We can massage that into the desired digits and exponent as in scale-exponent, but we won't have the round-off problem. Maybe. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/1> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 4

[cmucl-ticket] #10: round is sometimes wrong for numbers bigger than most-positive-fixnum
by cmucl 19 May '07

19 May '07

#10: round is sometimes wrong for numbers bigger than most-positive-fixnum --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19d Keywords: round | --------------------+------------------------------------------------------- {{{(round (+ 536870911 1.5d0))}}} should return 536870912 and 0.5d0. However, cmucl returns 536870913 and -0.5d0. The code in float.lisp for {{{%unary-round}}} appears to be wrong for numbers outside fixnum range. At the very least we should extend the range to {{{(signed-byte 32)}}}, but there would still be issues for other numbers. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/10> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

[cmucl-ticket] #9: parse-time mishandles invalid number of days in a month
by cmucl 02 May '07

02 May '07

#9: parse-time mishandles invalid number of days in a month --------------------+------------------------------------------------------- Reporter: rtoy | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: Core | Version: 19d Keywords: | --------------------+------------------------------------------------------- {{{ (format-universal-time t (parse-time "Feb 31 2000")) -> Thursday, 3/2/00 12:00:00 am EST }}} {{{parse-time}}} doesn't check to see if the day number makes sense for the given month. If this is fixed, don't forget that the number of days in February depends on if it's a leap year or not. -- Ticket URL: <http://trac.common-lisp.net/cmucl/ticket/9> cmucl <http://common-lisp.net/project/cmucl> cmucl

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cmucl-ticket May 2007