#190: FORMAT DOLLARSIGN fails to handle rounding negative arguments
----------------------------------+------------------------------
Reporter: Evenson Not Org | Owner: ehuelsmann
Type: defect | Status: new
Priority: critical | Milestone: 1.6.0
Component: interpreter | Version: 1.0
Resolution: | Keywords: ansi-conformance
Parent Tickets: |
----------------------------------+------------------------------
Description changed by Evenson Not Org:
Old description:
> In <http://article.gmane.org/gmane.lisp.armedbear.devel/2138> Marshall
> Abrams reports:
>
> {{{
>
> It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign
> directive's handling of negative numbers when it has to round up.
> (Forgive me if this is a known issue--I didn't find it when I searched
> the bug list and mailing list archives--or if there's something I'm
> misunderstanding.)
>
> The first group of examples use the F directive for comparison to show
> that the problem seems to be specific to dollarsign. (I added blank
> lines between example groups for easy reading.)
>
> The second group of examples illustrates a problem using dollarsign with
> negative numbers. The output is about 10x too large, and doesn't seem to
> be getting rounded properly. I'm guessing that the out of bounds error
> is the result of the same issue.
>
> The third group of examples shows that the problem doesn't seem to occur
> with positive numbers, although there's still an extra negative sign
> preprended.
>
> Thank you-
>
> Marshall Abrams
> }}}
>
> Armed Bear Common Lisp 1.0.0-svn-13663
> Java 1.6.0_29 Apple Inc.
> Java HotSpot(TM) 64-Bit Server VM
> Low-level initialization completed in 0.7 seconds.
> Startup completed in 2.211 seconds.
> Type ":help" for a list of available commands.
>
> CL-USER(1): (format t "~,vf" 3 -0.1768522)
> -0.177
> NIL
> CL-USER(2): (format t "~,vf" 2 -0.1768522)
> -0.18
> NIL
> CL-USER(3): (format t "~,vf" 1 -0.1768522)
> -0.2
> NIL
> CL-USER(4): (format t "~,vf" 0 -0.1768522)
> -0.
> NIL
>
> CL-USER(5): (format t "~$" -0.1768522)
> --1.6
> NIL
> CL-USER(6): (format t "~v$" 3 -0.1768522)
> --1.75
> NIL
> CL-USER(7): (format t "~v$" 2 -0.1768522)
> --1.6
> NIL
> CL-USER(8): (format t "~v$" 1 -0.1768522)
> #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type
> TYPE-ERROR
> Array index out of bounds: 2
> Restarts:
> 0: TOP-LEVEL Return to top level.
> [1] CL-USER(9): 0
> CL-USER(10): (format t "~v$" 0 -0.1768522)
> --0.
> NIL
>
> CL-USER(11): (format t "~$" 0.1768522)
> 0.18
> NIL
> CL-USER(12): (format t "~v$" 3 0.1768522)
> 0.177
> NIL
> CL-USER(13): (format t "~v$" 2 0.1768522)
> 0.18
> NIL
> CL-USER(14): (format t "~v$" 1 0.1768522)
> 0.2
> NIL
> CL-USER(15): (format t "~v$" 0 0.1768522)
> 0.
> NIL
> }}}
New description:
In <http://article.gmane.org/gmane.lisp.armedbear.devel/2138> Marshall
Abrams reports:
It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign directive's
handling of negative numbers when it has to round up. (Forgive me if this
is a known issue--I didn't find it when I searched the bug list and
mailing list archives--or if there's something I'm misunderstanding.)
The first group of examples use the F directive for comparison to show
that the problem seems to be specific to dollarsign. (I added blank lines
between example groups for easy reading.)
The second group of examples illustrates a problem using dollarsign with
negative numbers. The output is about 10x too large, and doesn't seem to
be getting rounded properly. I'm guessing that the out of bounds error is
the result of the same issue.
The third group of examples shows that the problem doesn't seem to occur
with positive numbers, although there's still an extra negative sign
prepended.
Thank you-
Marshall Abrams
* FAILURES
Armed Bear Common Lisp 1.0.0-svn-13663
Java 1.6.0_29 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.7 seconds.
Startup completed in 2.211 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (format t "~,vf" 3 -0.1768522)
-0.177
NIL
CL-USER(2): (format t "~,vf" 2 -0.1768522)
-0.18
NIL
CL-USER(3): (format t "~,vf" 1 -0.1768522)
-0.2
NIL
CL-USER(4): (format t "~,vf" 0 -0.1768522)
-0.
NIL
CL-USER(5): (format t "~$" -0.1768522)
--1.6
NIL
CL-USER(6): (format t "~v$" 3 -0.1768522)
--1.75
NIL
CL-USER(7): (format t "~v$" 2 -0.1768522)
--1.6
NIL
CL-USER(8): (format t "~v$" 1 -0.1768522)
#<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type
TYPE-ERROR
Array index out of bounds: 2
Restarts:
0: TOP-LEVEL Return to top level.
[1] CL-USER(9): 0
CL-USER(10): (format t "~v$" 0 -0.1768522)
--0.
NIL
CL-USER(11): (format t "~$" 0.1768522)
0.18
NIL
CL-USER(12): (format t "~v$" 3 0.1768522)
0.177
NIL
CL-USER(13): (format t "~v$" 2 0.1768522)
0.18
NIL
CL-USER(14): (format t "~v$" 1 0.1768522)
0.2
NIL
CL-USER(15): (format t "~v$" 0 0.1768522)
0.
NIL
}}}
--
--
Ticket URL: <http://abcl.org/trac/ticket/190#comment:13>
armedbear <http://abcl.org>
armedbear
#190: FORMAT DOLLARSIGN fails to handle rounding negative arguments
----------------------------------+------------------------------
Reporter: Evenson Not Org | Owner: ehuelsmann
Type: defect | Status: new
Priority: critical | Milestone: 1.6.0
Component: interpreter | Version: 1.0
Resolution: | Keywords: ansi-conformance
Parent Tickets: |
----------------------------------+------------------------------
Description changed by Evenson Not Org:
Old description:
> [http://article.gmane.org/gmane.lisp.armedbear.devel/2138 Marshall Abrams
> reports:]
>
> {{{
>
> It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign
> directive's handling of negative numbers when it has to round up.
> (Forgive me if this is a known issue--I didn't find it when I searched
> the bug list and mailing list archives--or if there's something I'm
> misunderstanding.)
>
> The first group of examples use the F directive for comparison to show
> that the problem seems to be specific to dollarsign. (I added blank
> lines between example groups for easy reading.)
>
> The second group of examples illustrates a problem using dollarsign with
> negative numbers. The output is about 10x too large, and doesn't seem to
> be getting rounded properly. I'm guessing that the out of bounds error
> is the result of the same issue.
>
> The third group of examples shows that the problem doesn't seem to occur
> with positive numbers, although there's still an extra negative sign
> preprended.
>
> Thank you-
>
> Marshall Abrams
>
> Armed Bear Common Lisp 1.0.0-svn-13663
> Java 1.6.0_29 Apple Inc.
> Java HotSpot(TM) 64-Bit Server VM
> Low-level initialization completed in 0.7 seconds.
> Startup completed in 2.211 seconds.
> Type ":help" for a list of available commands.
>
> CL-USER(1): (format t "~,vf" 3 -0.1768522)
> -0.177
> NIL
> CL-USER(2): (format t "~,vf" 2 -0.1768522)
> -0.18
> NIL
> CL-USER(3): (format t "~,vf" 1 -0.1768522)
> -0.2
> NIL
> CL-USER(4): (format t "~,vf" 0 -0.1768522)
> -0.
> NIL
>
> CL-USER(5): (format t "~$" -0.1768522)
> --1.6
> NIL
> CL-USER(6): (format t "~v$" 3 -0.1768522)
> --1.75
> NIL
> CL-USER(7): (format t "~v$" 2 -0.1768522)
> --1.6
> NIL
> CL-USER(8): (format t "~v$" 1 -0.1768522)
> #<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type
> TYPE-ERROR
> Array index out of bounds: 2
> Restarts:
> 0: TOP-LEVEL Return to top level.
> [1] CL-USER(9): 0
> CL-USER(10): (format t "~v$" 0 -0.1768522)
> --0.
> NIL
>
> CL-USER(11): (format t "~$" 0.1768522)
> 0.18
> NIL
> CL-USER(12): (format t "~v$" 3 0.1768522)
> 0.177
> NIL
> CL-USER(13): (format t "~v$" 2 0.1768522)
> 0.18
> NIL
> CL-USER(14): (format t "~v$" 1 0.1768522)
> 0.2
> NIL
> CL-USER(15): (format t "~v$" 0 0.1768522)
> 0.
> NIL
> }}}
New description:
In <http://article.gmane.org/gmane.lisp.armedbear.devel/2138> Marshall
Abrams reports:
{{{
It looks as if there's a bug in 1.0.0 with FORMAT's dollarsign directive's
handling of negative numbers when it has to round up. (Forgive me if this
is a known issue--I didn't find it when I searched the bug list and
mailing list archives--or if there's something I'm misunderstanding.)
The first group of examples use the F directive for comparison to show
that the problem seems to be specific to dollarsign. (I added blank lines
between example groups for easy reading.)
The second group of examples illustrates a problem using dollarsign with
negative numbers. The output is about 10x too large, and doesn't seem to
be getting rounded properly. I'm guessing that the out of bounds error is
the result of the same issue.
The third group of examples shows that the problem doesn't seem to occur
with positive numbers, although there's still an extra negative sign
preprended.
Thank you-
Marshall Abrams
}}}
Armed Bear Common Lisp 1.0.0-svn-13663
Java 1.6.0_29 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.7 seconds.
Startup completed in 2.211 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (format t "~,vf" 3 -0.1768522)
-0.177
NIL
CL-USER(2): (format t "~,vf" 2 -0.1768522)
-0.18
NIL
CL-USER(3): (format t "~,vf" 1 -0.1768522)
-0.2
NIL
CL-USER(4): (format t "~,vf" 0 -0.1768522)
-0.
NIL
CL-USER(5): (format t "~$" -0.1768522)
--1.6
NIL
CL-USER(6): (format t "~v$" 3 -0.1768522)
--1.75
NIL
CL-USER(7): (format t "~v$" 2 -0.1768522)
--1.6
NIL
CL-USER(8): (format t "~v$" 1 -0.1768522)
#<THREAD "interpreter" {10FA1B2D}>: Debugger invoked on condition of type
TYPE-ERROR
Array index out of bounds: 2
Restarts:
0: TOP-LEVEL Return to top level.
[1] CL-USER(9): 0
CL-USER(10): (format t "~v$" 0 -0.1768522)
--0.
NIL
CL-USER(11): (format t "~$" 0.1768522)
0.18
NIL
CL-USER(12): (format t "~v$" 3 0.1768522)
0.177
NIL
CL-USER(13): (format t "~v$" 2 0.1768522)
0.18
NIL
CL-USER(14): (format t "~v$" 1 0.1768522)
0.2
NIL
CL-USER(15): (format t "~v$" 0 0.1768522)
0.
NIL
}}}
--
--
Ticket URL: <http://abcl.org/trac/ticket/190#comment:12>
armedbear <http://abcl.org>
armedbear
#460: upgraded-array-element-type/class-of for arrays
-------------------------+----------------------------
Reporter: mevenson | Owner:
Type: defect | Status: new
Priority: major | Milestone: 1.5.1
Component: interpreter | Version: 1.6.0-dev
Keywords: | Parent Tickets:
-------------------------+----------------------------
Alan notes in <https://github.com/armedbear/abcl/issues/84>
{{{
No code of mine depends on this, but I was reading an article and it
prompted me to check types of arrays and how upgraded-array-element-type
works.
Bottom line is that it isn't consistent.
CL-USER> (make-array 1 :element-type '(unsigned-byte 16))
#(0)
CL-USER> (jobject-class *)
#<java class org.armedbear.lisp.BasicVector_UnsignedByte16 {6F28B4E2}>
CL-USER> (class-of (make-array 1 :element-type '(unsigned-byte 16)))
#<built-in-class vector {352D86C9}>
CL-USER> (upgraded-array-element-type '(unsigned-byte 16))
(unsigned-byte 16)
CL-USER> (make-array 1 :element-type '(unsigned-byte 17))
#(0)
CL-USER> (jobject-class *)
#<java class org.armedbear.lisp.BasicVector_UnsignedByte32 {1C49E33C}>
CL-USER> (upgraded-array-element-type '(unsigned-byte 17))
t
CL-USER> (class-of (make-array 1 :element-type '(unsigned-byte 17)))
#<built-in-class vector {352D86C9}>
Summary:
Implementation of arrays of unsigned byte 16 vs 17 are different
class-of reports the same type
upgraded-array-element-type of (unsigned-byte 17) reports t, but it is
in fact (unsigned-byte 32)
trying to set array element of (unsigned-byte 17) to int larger than
2^17 works, but not setting to a symbol, as type t would imply
}}}
--
Ticket URL: <http://abcl.org/trac/ticket/460>
armedbear <http://abcl.org>
armedbear