[ clisp-Bugs-3524255 ] ANSI CL forbids mixed-type complex numbers

SourceForge.net <[email protected]>
Newsgroups gmane.lisp.clisp.devel
Message-ID <[email protected]>
Bugs item #3524255, was opened at 2012-05-06 22:38
Message generated for change (Comment added) made by johnwcowan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3524255&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
>Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: John Cowan (johnwcowan)
Assigned to: Bruno Haible (haible)
Summary: ANSI CL forbids mixed-type complex numbers

Initial Comment:
CLHS (under Function COMPLEX) says that the real and imaginary parts of a complex numbers must either be both rational or both of the same float type, and if they are not, floating-point coercion must be done.  One of the given examples is (complex 1 .99) =>  #C(1.0 0.99).

But in CLISP, (integerp (realpart (complex 1 .99)) => #t.  This means that the real part is being stored as a rational number, since there is no coercion from floats to rationals.  COMPLEX (and #C) should be changed to make sure both parts are either rational or of the same float type.

This bug is present both in 2.48 on Cygwin and 2.44.1 on Ubuntu Lucid (both from binary packages).  Here are the clisp --version outputs:

GNU CLISP 2.48 (2009-07-28) (built on ATGRZWN502840.avl01.avlcorp.lan [157.247.26.41])
Software: GNU C 4.3.4 20090804 (release) 1
gcc-4 -O2 -pipe  -g -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -Wl,--stack,8388608 -Wl,--enable-auto-import  /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a /usr/lib/libreadline.dll.a -lncurses /usr/lib/libavcall.a /usr/lib/libcallback.a /usr/lib/libiconv.dll.a -L/usr/lib -lsigsegv
SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED
libsigsegv 2.8
libiconv 1.13
libreadline 6.0
Features:
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
 GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX CYGWIN)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.48/
User language: ENGLISH
Machine: I686 (I686) LNGNYCL-FDB00M1.legal.regn.net [192.168.1.118]

GNU CLISP 2.44.1 (2008-02-23) (built 3476024583) (memory 3544628985)
Software: GNU C 4.4.3 
i486-linux-gnu-gcc -g -O2 -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -Wl,-Bsymbolic-functions  -x none /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.5
libreadline 5.2
Features: 
(ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER BERKELEY-DB CLX-ANSI-COMMON-LISP CLX READLINE REGEXP SYSCALLS I18N
 LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES
 SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline linux clx bdb)
Installation directory: /usr/lib/clisp-2.44.1/
User language: ENGLISH
Machine: I686 (I686) pubuntu [127.0.0.1]


----------------------------------------------------------------------

>Comment By: John Cowan (johnwcowan)
Date: 2012-05-07 07:11

Message:
I agree that it is documented, but deny that it is a valid ANSI CL
extension.  Section 1.6 of the CLHS says: "An implementation can have
extensions, provided they do not alter the behavior of conforming code and
provided they are not explicitly prohibited by this standard."  But
(integerp (realpart (complex 1 2.0))) is conforming code, and the standard
requires that it return NIL due to floating-point contagion.  Making it
return T instead is altering its behavior, and makes the implementation
non-conformant.

A legitimate way of providing mixed-type complex numbers is to introduce an
implementation-dependent function and/or lexical syntax for creating them.



----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2012-05-07 06:51

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

----------------------------------------------------------------------

Comment By: Bruno Haible (haible)
Date: 2012-05-07 04:42

Message:
This is a documented feature, not a bug:
http://www.clisp.org/impnotes.html#complex-comp


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3524255&group_id=1355

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.