From: Jeronimo Pellegrini
Subject: [ANN] Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnj1p6$nsb$1@aioe.org>
Spartns is a SPARse TeNSor representation library:
http://aleph0.info/spartns/
I started writing this months ago to replace what I used before, which
was basically (GETHASH `(i j k l) matrix) and its SETF form. I wanted to
be able to run through all indices and values in the tensor very fast,
and the hashtables were not fast enough for several reasons (not
specialized on the data type, necessarily involves boxing because there
is a non-local function call, etc).
It's in a very eraly stage: there is no support for operations and only
basic traversals are available, and there are only toy tests.
But there are already some features implemented:
* Represents mappings from one dimension onto another using any
scheme you want (there are two built-in schemes, hash and
compressed-vector, but you can roll your own and plug it);
* Flexible: works with any data type;
* Heavily optimized: traversing the tensor is extremely fast
(in one specific situation, it was 10 times faster than a naive
implementation in C++);
* Somewhat portable: works with SBCL, ABCL, and Clisp.
Probably works also with ECL, GCL and CMUCL (not fully tested);
* Easy to use, with introductory documentation (not only on-line);
* Comes with description of the internals of the library
It's the first time I release Common Lisp code, so there are probably
lots of issues I didn't even dream about. :-) Suggestions and criticism
are absolutely welcome!
I hope it is useful.
J.
On Jan 27, 11:49 pm, Jeronimo Pellegrini <····@aleph0.info> wrote:
> Spartns is a SPARse TeNSor representation library:
>
> http://aleph0.info/spartns/
>
> I started writing this months ago to replace what I used before, which
> was basically (GETHASH `(i j k l) matrix) and its SETF form. I wanted to
> be able to run through all indices and values in the tensor very fast,
> and the hashtables were not fast enough for several reasons (not
> specialized on the data type, necessarily involves boxing because there
> is a non-local function call, etc).
>
> It's in a very eraly stage: there is no support for operations and only
> basic traversals are available, and there are only toy tests.
> But there are already some features implemented:
>
> * Represents mappings from one dimension onto another using any
> scheme you want (there are two built-in schemes, hash and
> compressed-vector, but you can roll your own and plug it);
> * Flexible: works with any data type;
> * Heavily optimized: traversing the tensor is extremely fast
> (in one specific situation, it was 10 times faster than a naive
> implementation in C++);
> * Somewhat portable: works with SBCL, ABCL, and Clisp.
> Probably works also with ECL, GCL and CMUCL (not fully tested);
> * Easy to use, with introductory documentation (not only on-line);
> * Comes with description of the internals of the library
>
> It's the first time I release Common Lisp code, so there are probably
> lots of issues I didn't even dream about. :-) Suggestions and criticism
> are absolutely welcome!
>
> I hope it is useful.
>
> J.
According to my library evaluation scheme
http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-of-drive.html
you've done everything great except the easiest part, asdf file. Add
something like this http://paste.lisp.org/display/54914 and comment
the load parts.
Why does spartns doesn't spartns work with LW, are you using
implementation specific code?
cheers
Slobodan
From: Jeronimo Pellegrini
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnjg23$2oi$1@aioe.org>
On 2008-01-28, Slobodan Blazeski <·················@gmail.com> wrote:
> According to my library evaluation scheme
> http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-of-drive.html
> you've done everything great except the easiest part, asdf file. Add
> something like this http://paste.lisp.org/display/54914 and comment
> the load parts.
OK - thanks for that!
I tried to use the ASDF definition you suggested, but when I
try to load the library with ASDF, it doesn't work because
I have top-level macros with side-effects. I'll work on that
and post a new version of the library later.
> Why does spartns doesn't spartns work with LW, are you using
> implementation specific code?
No... I actually don't knw why it didn't work with CMUCL.
ECL and GCL failed the tests just because they have a different
understanding of what type "1.0" is, if I remember correctly
(single-float versus short-float, etc).
I will make the tests more robust later.
As to LW, I didn't test it because I don't have it installed.
But I really did not use anything that wasn't standard...
J.
On Jan 28, 3:52 am, Jeronimo Pellegrini <····@aleph0.info> wrote:
> On 2008-01-28, Slobodan Blazeski <·················@gmail.com> wrote:
>
> > According to my library evaluation scheme
> >http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-...
> > you've done everything great except the easiest part, asdf file. Add
> > something like thishttp://paste.lisp.org/display/54914 and comment
> > the load parts.
>
> OK - thanks for that!
> I tried to use the ASDF definition you suggested, but when I
> try to load the library with ASDF, it doesn't work because
> I have top-level macros with side-effects. I'll work on that
> and post a new version of the library later.
>
> > Why does spartns doesn't spartns work with LW, are you using
> > implementation specific code?
>
> No... I actually don't knw why it didn't work with CMUCL.
>
> ECL and GCL failed the tests just because they have a different
> understanding of what type "1.0" is, if I remember correctly
> (single-float versus short-float, etc).
> I will make the tests more robust later.
>
> As to LW, I didn't test it because I don't have it installed.
> But I really did not use anything that wasn't standard...
>
> J.
That sounds good, I'll test with Allegro & LW after you pack it with
asdf. It's a pitty to have a quality library broken across major
implementations especially when it doesn't depend on anything but the
ANSI standard. If you can it would be good to install few other
implementations and make it work flawless with all of them, believe
the one day effort will return to you with high interest, especially
when you'll understand that you're depending on a compiler specific
interpretation of standard. Take this thread for an example
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/4d024637d8c90dcc/7cb834d22c1bfc63?lnk=gst&q=+SBCL+complains+where+Lispwork+does+not#7cb834d22c1bfc63
I'm sure there will be a people interested in your library who lack
experience, time or both to patch it. Don't chase them way, make your
name a label for high quality libraries.
cheers
Slobodan
From: Jeronimo Pellegrini
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnkmg5$pq1$2@aioe.org>
On 2008-01-28, Slobodan Blazeski <·················@gmail.com> wrote:
> That sounds good, I'll test with Allegro & LW after you pack it with
> asdf. It's a pitty to have a quality library broken across major
> implementations especially when it doesn't depend on anything but the
> ANSI standard. If you can it would be good to install few other
> implementations and make it work flawless with all of them, believe
> the one day effort will return to you with high interest, especially
> when you'll understand that you're depending on a compiler specific
> interpretation of standard.
Yes -- portability is a major goal for me; I'll update the package in
the next days.
Thanks for the ASDF definition file!
J.
From: Jeronimo Pellegrini
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnkugm$p5t$1@aioe.org>
OK -- version 0.0.2 is ready. I am not sure if I got the ASDF part
right, but evaluating
(asdf:operate 'asdf:load-op 'spartns)
(asdf:operate 'asdf:test-op 'spartns)
Works (and all tests pass) on SBCL, CMUCL, Clisp and ABCL.
I couldn't get ASDF to run nicely on ECL and GCL (this may be some
problem with my setup -- I don't know).
ECL is actually OK (without ASDF):
(load "utils.lisp")
(load "lisp-unit.lisp")
(load "spartns.lisp")
(load "tests.lisp")
This runs all tests, and they all pass on ECL, but GCL complains
about the type of floating-point numbers.
*However*, if I agree with GCL and say 0.0 is long-float, then
GCL also passes all tests! 8-)
I don't have other Common Lisp environments installed.
J.
On Jan 28, 5:05 pm, Jeronimo Pellegrini <····@aleph0.info> wrote:
> OK -- version 0.0.2 is ready. I am not sure if I got the ASDF part
> right, but evaluating
>
> (asdf:operate 'asdf:load-op 'spartns)
> (asdf:operate 'asdf:test-op 'spartns)
>
> Works (and all tests pass) on SBCL, CMUCL, Clisp and ABCL.
>
> I couldn't get ASDF to run nicely on ECL and GCL (this may be some
> problem with my setup -- I don't know).
>
> ECL is actually OK (without ASDF):
> (load "utils.lisp")
> (load "lisp-unit.lisp")
> (load "spartns.lisp")
> (load "tests.lisp")
> This runs all tests, and they all pass on ECL, but GCL complains
> about the type of floating-point numbers.
>
> *However*, if I agree with GCL and say 0.0 is long-float, then
> GCL also passes all tests! 8-)
>
> I don't have other Common Lisp environments installed.
>
> J.
Works with LW & ALlgero , however http://aleph0.info/spartns/spartns-0.0.2.tar.gz
doesn't have any asd file. What's the official download for full
package , cliki search doesn't shows anything ?
cheers
Slobodan
LW
DEEP: 9 assertions passed, 0 failed.
DEFSCHEME: 5 assertions passed, 0 failed.
DEFSPARTN: 2 assertions passed, 0 failed.
DO-TRAVERSE-HASH: 1 assertions passed, 0 failed.
EXPAND-SCHEME: 4 assertions passed, 0 failed.
SPARTN-CONVERT: 2 assertions passed, 0 failed.
TEST-SCHEME-CVECTOR: 15 assertions passed, 0 failed.
TEST-SCHEME-HASH: 15 assertions passed, 0 failed.
TRAVERSALS: 12 assertions passed, 0 failed.
W/SPARTNS: 3 assertions passed, 0 failed.
TOTAL: 68 assertions passed, 0 failed, 0 execution errors.
Allegro
; While compiling COPY-HCD* in F:\Program Files\LispWorks Personal
\libraries\spartns-0.0.2\tests.lisp:
Warning: Variable #:DATA-2058 is never used.
; While compiling COPY-CCD* in F:\Program Files\LispWorks Personal
\libraries\spartns-0.0.2\tests.lisp:
Warning: Variable #:DATA-2233 is never used.
; While compiling COPY-HHCCHCF in F:\Program Files\LispWorks Personal
\libraries\spartns-0.0.2\tests.lisp:
Warning: Variable #:DATA-2479 is never used.
; While compiling COPY-CCHHCHF in F:\Program Files\LispWorks Personal
\libraries\spartns-0.0.2\tests.lisp:
Warning: Variable #:DATA-2772 is never used.
; Fast loading F:\Program Files\LispWorks Personal\libraries
\spartns-0.0.2\tests.fasl
DEEP: 9 assertions passed, 0 failed.
DEFSCHEME: 5 assertions passed, 0 failed.
DEFSPARTN: 2 assertions passed, 0 failed.
DO-TRAVERSE-HASH: 1 assertions passed, 0 failed.
EXPAND-SCHEME: 4 assertions passed, 0 failed.
SPARTN-CONVERT: 2 assertions passed, 0 failed.
TEST-SCHEME-CVECTOR: 15 assertions passed, 0 failed.
TEST-SCHEME-HASH: 15 assertions passed, 0 failed.
TRAVERSALS: 12 assertions passed, 0 failed.
W/SPARTNS: 3 assertions passed, 0 failed.
TOTAL: 68 assertions passed, 0 failed, 0 execution errors.
From: Jeronimo Pellegrini
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnl7gr$ptf$1@aioe.org>
On 2008-01-28, Slobodan Blazeski <·················@gmail.com> wrote:
> Works with LW & ALlgero , however http://aleph0.info/spartns/spartns-0.0.2.tar.gz
> doesn't have any asd file. What's the official download for full
> package , cliki search doesn't shows anything ?
Oops! Sorry.
It should work now (it on cliki.net).
I hope everything is fine now...
J.
In article <············@aioe.org> Jeronimo
Pellegrini<···@aleph0.info> wrote:
> On 2008-01-28, Slobodan Blazeski <·················@gmail.com> wrote:
>> According to my library evaluation scheme
>> http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-
>> of-drive.html you've done everything great except the easiest part,
>> asdf file. Add something like this
>> http://paste.lisp.org/display/54914 and comment the load parts.
> OK - thanks for that!
> I tried to use the ASDF definition you suggested, but when I
> try to load the library with ASDF, it doesn't work because
> I have top-level macros with side-effects. I'll work on that
> and post a new version of the library later.
>> Why does spartns doesn't spartns work with LW, are you using
>> implementation specific code?
> No... I actually don't knw why it didn't work with CMUCL.
> ECL and GCL failed the tests just because they have a different
> understanding of what type "1.0" is, if I remember
> correctly(single-float versus short-float, etc).
> I will make the tests more robust later.
> As to LW, I didn't test it because I don't have it installed.
> But I really did not use anything that wasn't standard...
> J.
This is what I'm using sometimes:
#.(coerce 1.0 'single-float)
It converts 1.0 to the correct type.
Off course there might be better ways, of which I don't know.
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
From: alien_guy
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnk3hc$qvh$1@aioe.org>
On Mon, 28 Jan 2008 08:09:23 +0000, malkia wrote:
> In article <············@aioe.org> Jeronimo Pellegrini<···@aleph0.info>
> wrote:
> This is what I'm using sometimes:
>
> #.(coerce 1.0 'single-float)
>
> It converts 1.0 to the correct type.
>
> Off course there might be better ways, of which I don't know.
1.0f0
From: Jeronimo Pellegrini
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnk3s4$rti$1@aioe.org>
On 2008-01-28, alien_guy <·@l.org> wrote:
> On Mon, 28 Jan 2008 08:09:23 +0000, malkia wrote:
>
>> In article <············@aioe.org> Jeronimo Pellegrini<···@aleph0.info>
>> wrote:
>> This is what I'm using sometimes:
>>
>> #.(coerce 1.0 'single-float)
>>
>> It converts 1.0 to the correct type.
>>
>> Off course there might be better ways, of which I don't know.
>
> 1.0f0
That's the problem...
GCL:
> (type-of 0f0)
LONG-FLOAT
SBCL:
* (type-of 0f0)
SINGLE-FLOAT
So (assert (eql (type-of x) y)) doesn't necesarily work for this.
J.
On Jan 28, 9:31 am, Jeronimo Pellegrini <····@aleph0.info> wrote:
> On 2008-01-28, alien_guy <····@l.org> wrote:
>
> > On Mon, 28 Jan 2008 08:09:23 +0000, malkia wrote:
>
> >> In article <············@aioe.org> Jeronimo Pellegrini<····@aleph0.info>
> >> wrote:
> >> This is what I'm using sometimes:
>
> >> #.(coerce 1.0 'single-float)
>
> >> It converts 1.0 to the correct type.
>
> >> Off course there might be better ways, of which I don't know.
>
> > 1.0f0
>
> That's the problem...
>
> GCL:
>
> > (type-of 0f0)
That's definately a bug , is GCL being maintaineed?
>
> LONG-FLOAT
>
> SBCL:
>
> * (type-of 0f0)
>
> SINGLE-FLOAT
>
> So (assert (eql (type-of x) y)) doesn't necesarily work for this.
>
> J.
From: Jeronimo Pellegrini
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnkmjt$pq1$3@aioe.org>
On 2008-01-28, Slobodan Blazeski <·················@gmail.com> wrote:
> That's definately a bug , is GCL being maintaineed?
As far as I know, yes. I'll report the bug then.
(I thought the standard allowed this to be implementation specific,
but I'll check again).
J.
On Jan 28, 2:50 pm, Jeronimo Pellegrini <····@aleph0.info> wrote:
> On 2008-01-28, Slobodan Blazeski <·················@gmail.com> wrote:
>
> > That's definately a bug , is GCL being maintaineed?
>
> As far as I know, yes. I'll report the bug then.
> (I thought the standard allowed this to be implementation specific,
> but I'll check again).
>
> J.
You could ask in a separate thread just to be sure but both Allegro &
LW return single-float
CG-USER(1): (type-of 0f0) ;allegro
SINGLE-FLOAT
CL-USER 1 > (type-of 0f0) ;lw
SINGLE-FLOAT
Beside sbcl on linux those are the only implementations I use.
cheers
Slobodan
From: alien_guy
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnk7pb$8ne$1@aioe.org>
On Mon, 28 Jan 2008 09:31:01 +0100, Jeronimo Pellegrini wrote:
> On 2008-01-28, alien_guy <·@l.org> wrote:
>> On Mon, 28 Jan 2008 08:09:23 +0000, malkia wrote:
>>
>>> In article <············@aioe.org> Jeronimo
>>> Pellegrini<···@aleph0.info> wrote:
>>> This is what I'm using sometimes:
>>>
>>> #.(coerce 1.0 'single-float)
>>>
>>> It converts 1.0 to the correct type.
>>>
>>> Off course there might be better ways, of which I don't know.
>>
>> 1.0f0
>
> That's the problem...
>
>
> GCL:
>
> > (type-of 0f0)
>
> LONG-FLOAT
the easy answer is "Don't use GCL unless you really have to(or someone's
pointing a gun to your head)"
Jeronimo Pellegrini <···@aleph0.info> writes:
> On 2008-01-28, alien_guy <·@l.org> wrote:
>> On Mon, 28 Jan 2008 08:09:23 +0000, malkia wrote:
>>
>>> In article <············@aioe.org> Jeronimo Pellegrini<···@aleph0.info>
>>> wrote:
>>> This is what I'm using sometimes:
>>>
>>> #.(coerce 1.0 'single-float)
>>>
>>> It converts 1.0 to the correct type.
>>>
>>> Off course there might be better ways, of which I don't know.
>>
>> 1.0f0
>
> That's the problem...
>
>
> GCL:
>
> > (type-of 0f0)
>
> LONG-FLOAT
>
>
>
> SBCL:
>
> * (type-of 0f0)
>
> SINGLE-FLOAT
>
>
> So (assert (eql (type-of x) y)) doesn't necesarily work for this.
You are testing the wrong thing!
CLHS 2.3.2.2 says that:
An implementation may provide one or more kinds of float that
collectively make up the type float. The letters s, f, d, and l
(or their respective uppercase equivalents) explicitly specify the
use of the types short-float, single-float, double-float, and
long-float, respectively.
Note the very meaningfull "MAY" provide.
What you should test to check whether your implementation is conformant is:
(every (lambda (letter type)
(typep (read-from-string (format nil "1.0~A0" letter)) type))
'(#\s #\f #\d #\l)
'(short-float single-float double-float long-float))
All the implementations installed on my system behave correctly in
this respect, including gcl 2.6.7:
[···@thalassa ~]$ clall '(every (lambda (letter type) (typep (read-from-string (format nil "1.0~A0" letter)) type)) (quote (#\s #\f #\d #\l)) (quote (short-float single-float double-float long-float)))'
========================================================================
CLISP 2.41 (2006-10-13) (built on thalassa.lan.informatimago.com [192.168.1.198])
Evaluation of
(EVERY
(LAMBDA (LETTER TYPE)
(TYPEP (READ-FROM-STRING (FORMAT NIL "1.0~A0" LETTER)) TYPE))
'(#\s #\f #\d #\l) '(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT))
produced nothing on *STANDARD-OUTPUT*
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> T
========================================================================
SBCL 1.0.12-gentoo
Evaluation of
(EVERY
(LAMBDA (LETTER TYPE)
(TYPEP (READ-FROM-STRING (FORMAT NIL "1.0~A0" LETTER)) TYPE))
'(#\s #\f #\d #\l) '(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT))
produced nothing on *STANDARD-OUTPUT*
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> T
========================================================================
CMU Common Lisp CVS 19c 19c-release + minimal debian patches (19C)
Evaluation of
(EVERY
(LAMBDA (LETTER TYPE)
(TYPEP (READ-FROM-STRING (FORMAT NIL "1.0~A0" LETTER)) TYPE))
'(#\s #\f #\d #\l)
'(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT))
produced nothing on *STANDARD-OUTPUT*
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> T
========================================================================
GNU Common Lisp (GCL) GCL 2.6.7
Evaluation of
(EVERY (LAMBDA (LETTER TYPE)
(TYPEP (READ-FROM-STRING (FORMAT NIL "1.0~A0" LETTER)) TYPE))
'(#\s #\f #\d #\l)
'(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT))
produced nothing on *STANDARD-OUTPUT*
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> T
========================================================================
ECL 0.9g
Evaluation of
(EVERY
(LAMBDA (LETTER TYPE)
(TYPEP (READ-FROM-STRING (FORMAT NIL "1.0~A0" LETTER)) TYPE))
'(#\s #\f #\d #\l)
'(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT))
produced nothing on *STANDARD-OUTPUT*
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> T
========================================================================
[···@thalassa ~]$
Now what happens, is that not all the implementations have the same
set of floating point types. Of those I have, only clisp have 4
distinct floating point types. The others only have two, I guess 32
and 64-bit IEEE754 floats. gcl happens to name SHORT-FLOAT the small
one, and SINGLE-FLOAT, DOUBLE-FLOAT and LONG-FLOAT the big one,
which is perfectly legal. See
http://www.lispworks.com/documentation/HyperSpec/Body/t_short_.htm
[···@thalassa ~]$ clall '(let ((types (quote (short-float single-float double-float long-float)))) (dolist (from types) (format t "~%~12A " from) (dolist (to types) (format t "~4A" (typep (coerce 1.0e0 from) to)))))'
========================================================================
CLISP 2.41 (2006-10-13) (built on thalassa.lan.informatimago.com [192.168.1.198])
Evaluation of
(LET ((TYPES '(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT)))
(DOLIST (FROM TYPES) (FORMAT T "~%~12A " FROM)
(DOLIST (TO TYPES) (FORMAT T "~4A" (TYPEP (COERCE 1.0 FROM) TO)))))
produced the following *STANDARD-OUTPUT* (lines excluded):
------------------------------------------------------------------------
SHORT-FLOAT T NIL NIL NIL
SINGLE-FLOAT NIL T NIL NIL
DOUBLE-FLOAT NIL NIL T NIL
LONG-FLOAT NIL NIL NIL T
------------------------------------------------------------------------
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> NIL
========================================================================
SBCL 1.0.12-gentoo
Evaluation of
(LET ((TYPES '(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT)))
(DOLIST (FROM TYPES)
(FORMAT T "~%~12A " FROM)
(DOLIST (TO TYPES) (FORMAT T "~4A" (TYPEP (COERCE 1.0 FROM) TO)))))
produced the following *STANDARD-OUTPUT* (lines excluded):
------------------------------------------------------------------------
SHORT-FLOAT T T NIL NIL
SINGLE-FLOAT T T NIL NIL
DOUBLE-FLOAT NIL NIL T T
LONG-FLOAT NIL NIL T T
------------------------------------------------------------------------
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> NIL
========================================================================
CMU Common Lisp CVS 19c 19c-release + minimal debian patches (19C)
Evaluation of
(LET ((TYPES '(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT)))
(DOLIST (FROM TYPES)
(FORMAT T "~%~12A " FROM)
(DOLIST (TO TYPES) (FORMAT T "~4A" (TYPEP (COERCE 1.0 FROM) TO)))))
produced the following *STANDARD-OUTPUT* (lines excluded):
------------------------------------------------------------------------
SHORT-FLOAT T T NIL NIL
SINGLE-FLOAT T T NIL NIL
DOUBLE-FLOAT NIL NIL T T
LONG-FLOAT NIL NIL T T
------------------------------------------------------------------------
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> NIL
========================================================================
GNU Common Lisp (GCL) GCL 2.6.7
Evaluation of
(LET ((TYPES '(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT)))
(DOLIST (FROM TYPES)
(FORMAT T "~%~12A " FROM)
(DOLIST (TO TYPES) (FORMAT T "~4A" (TYPEP (COERCE 1.0 FROM) TO)))))
produced the following *STANDARD-OUTPUT* (lines excluded):
------------------------------------------------------------------------
SHORT-FLOAT T NIL NIL NIL
SINGLE-FLOAT NIL T T T
DOUBLE-FLOAT NIL T T T
LONG-FLOAT NIL T T T
------------------------------------------------------------------------
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> NIL
========================================================================
ECL 0.9g
Evaluation of
(LET ((TYPES '(SHORT-FLOAT SINGLE-FLOAT DOUBLE-FLOAT LONG-FLOAT)))
(DOLIST (FROM TYPES)
(FORMAT T "~%~12A " FROM)
(DOLIST (TO TYPES) (FORMAT T "~4A" (TYPEP (COERCE 1.0 FROM) TO)))))
produced the following *STANDARD-OUTPUT* (lines excluded):
------------------------------------------------------------------------
SHORT-FLOAT T T NIL NIL
SINGLE-FLOAT T T NIL NIL
DOUBLE-FLOAT NIL NIL T T
LONG-FLOAT NIL NIL T T
------------------------------------------------------------------------
produced nothing on *ERROR-OUTPUT*
produced no error
produced the following vals:
--> NIL
========================================================================
[···@thalassa ~]$
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
On Jan 28, 8:20 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Now what happens, is that not all the implementations have the same
> set of floating point types. Of those I have, only clisp have 4
> distinct floating point types. The others only have two, I guess 32
> and 64-bit IEEE754 floats. gcl happens to name SHORT-FLOAT the small
> one, and SINGLE-FLOAT, DOUBLE-FLOAT and LONG-FLOAT the big one,
> which is perfectly legal.
Legal, yes. But a perfectly legal response to (type-of 0f0) is (error
"Out of memory"). The ANSI spec gives a lot of leeway in some areas,
expecting the rest to be sorted out as quality-of-implementation
issues. As a user, I fully expect a CL implementation that runs on
general purpose hardware to conform to IEEE 754 and to make the
obvious correspondence between Lisp types and IEEE 754 types, i.e.
single-float being single-precision and double-float being double-
precision. It's not that there can't be bugs in implementations, and
I would assume/hope the gcl maintainers would consider this a bug. If
not, I wouldn't take it seriously as an implementation.
To the OP, you might want to put a check in your system to the effect
of:
#-ieee-floating-point
(cerror "Continue loading the system anyway"
"This implementation does not purport implement IEEE floating
point semantics")
From: Waldek Hebisch
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnqf80$ivb$1@z-news.pwr.wroc.pl>
Thomas F. Burdick <········@gmail.com> wrote:
> On Jan 28, 8:20 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>
> > Now what happens, is that not all the implementations have the same
> > set of floating point types. Of those I have, only clisp have 4
> > distinct floating point types. The others only have two, I guess 32
> > and 64-bit IEEE754 floats. gcl happens to name SHORT-FLOAT the small
> > one, and SINGLE-FLOAT, DOUBLE-FLOAT and LONG-FLOAT the big one,
> > which is perfectly legal.
>
> Legal, yes. But a perfectly legal response to (type-of 0f0) is (error
> "Out of memory"). The ANSI spec gives a lot of leeway in some areas,
> expecting the rest to be sorted out as quality-of-implementation
> issues. As a user, I fully expect a CL implementation that runs on
> general purpose hardware to conform to IEEE 754 and to make the
> obvious correspondence between Lisp types and IEEE 754 types, i.e.
> single-float being single-precision and double-float being double-
> precision. It's not that there can't be bugs in implementations, and
> I would assume/hope the gcl maintainers would consider this a bug. If
> not, I wouldn't take it seriously as an implementation.
>
Well, as a user if I give integer arguments to floating point
functions I expect double precision result. But Ansi says to
the result is single-float. I consider this as a bug in Ansi
standard. Now, I do not know the real reason that single-float
in gcl is the same as double-float. But making single-float
the same as double-float looks like reasonable way to correct
problem with Ansi spec.
BTW: I do _not_ expect Ansi Lisp to fully conform to IEEE 754:
IEEE says to if x is NaN (not a number) then x is not equal to x.
But in a reasonable Lisp implementation (eq x x) is always true
(I was unable to find any normative statement saying this, but
othewise almost everything that standard says about evaluation
is meaningless). Since beeing eq in Lisp implies beeing equal
Lisp can not treat Nan-s in IEEE way. So either Lisp has to
forbid Nan-s (which means only partial IEEE support, but is
probably the best choice), or break Ansi rules, or break IEEE
rules.
--
Waldek Hebisch
·······@math.uni.wroc.pl
From: John Thingstad
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <op.t5rbdwfsut4oq5@pandora.alfanett.no>
P� Wed, 30 Jan 2008 19:21:52 +0100, skrev Waldek Hebisch
<·······@math.uni.wroc.pl>:
>>
>
> Well, as a user if I give integer arguments to floating point
> functions I expect double precision result. But Ansi says to
> the result is single-float. I consider this as a bug in Ansi
> standard.
Why?
The is NO general way to convert float numbers back to integer's without
the loss of precision.
The approach I use is to introduce a tuple consisting of a value and a
epsilon.
In the general case epsilon is the radius of a n dimensional sphere around
the value where n is the number of free variables. For this specific case
it reduces to two points (value + eps) and (value - eps).
Usually numeric functions take the eps as a argument and either return a
value with a uncertainty within that eps or fail. (That means it has to
calulate the error term.)
In a professional math systems it might choose either short, long or
arbitrary precision float object to represent that value.
> Now, I do not know the real reason that single-float
> in gcl is the same as double-float. But making single-float
> the same as double-float looks like reasonable way to correct
> problem with Ansi spec.
>
Only if you don't give a damn about efficiency. Many numeric processors
can calulate several short-float calculations in paralell but only one
long-float. In the C library all calculations in the math library are done
in double. Since gcc compiles to C I wouldn't be suprised if this is why
it is double.
(This is one of the reasons Fortran is faster than C for float
calulations, as is CMUCL/SBCL sometimes)
> BTW: I do _not_ expect Ansi Lisp to fully conform to IEEE 754:
> IEEE says to if x is NaN (not a number) then x is not equal to x.
> But in a reasonable Lisp implementation (eq x x) is always true
> (I was unable to find any normative statement saying this, but
> othewise almost everything that standard says about evaluation
> is meaningless). Since beeing eq in Lisp implies beeing equal
> Lisp can not treat Nan-s in IEEE way.
eq means the places are to the SAME object. This need not be true for
numbers of characters. Use eql.
--------------
John Thingstad
From: Waldek Hebisch
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnqovv$s32$1@z-news.pwr.wroc.pl>
John Thingstad <·······@online.no> wrote:
> P? Wed, 30 Jan 2008 19:21:52 +0100, skrev Waldek Hebisch
> <·······@math.uni.wroc.pl>:
>
> >>
> >
> > Well, as a user if I give integer arguments to floating point
> > functions I expect double precision result. But Ansi says to
> > the result is single-float. I consider this as a bug in Ansi
> > standard.
>
> Why?
>
Integers are "most precise" numbers. It makes sense to preserve
as much of this accuracy as possible when converting them to
floats. Since floating point formats more precise than double
are available on only on some platforms, double is most precise
format which should be "always" available. Having default which
is likely to give significant loss of precision is inconsistent
with the rest of the language: normally one gets "slow but
correct" behaviour and needs declaration to choose fast, but
unsafe variants.
> > Now, I do not know the real reason that single-float
> > in gcl is the same as double-float. But making single-float
> > the same as double-float looks like reasonable way to correct
> > problem with Ansi spec.
> >
>
> Only if you don't give a damn about efficiency. Many numeric processors
> can calulate several short-float calculations in paralell but only one
> long-float.
gcl short-float _is_ single precision, so you can get efficiency if
single precision is accurate enough for you.
--
Waldek Hebisch
·······@math.uni.wroc.pl
From: Juho Snellman
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <87fxwf5fcy.fsf@vasara.proghammer.com>
Waldek Hebisch <·······@math.uni.wroc.pl> writes:
> BTW: I do _not_ expect Ansi Lisp to fully conform to IEEE 754:
> IEEE says to if x is NaN (not a number) then x is not equal to x.
> But in a reasonable Lisp implementation (eq x x) is always true
> (I was unable to find any normative statement saying this, but
> othewise almost everything that standard says about evaluation
> is meaningless).
Not true. CLHS on EQ:
An implementation is permitted to make ``copies'' of characters and
numbers at any time. The effect is that Common Lisp makes no
guarantee that eq is true even when both its arguments are ``the
same thing'' if that thing is a character or number.
A sketch of a reasonable implementation strategy that could result in
(let ((x 1)) (eq x x)) evaluating to NIL:
http://groups.google.com/group/comp.lang.lisp/msg/8767a6c7cf23286d
--
Juho Snellman
From: Waldek Hebisch
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnqnu4$rdd$1@z-news.pwr.wroc.pl>
Juho Snellman <······@iki.fi> wrote:
> Waldek Hebisch <·······@math.uni.wroc.pl> writes:
> > BTW: I do _not_ expect Ansi Lisp to fully conform to IEEE 754:
> > IEEE says to if x is NaN (not a number) then x is not equal to x.
> > But in a reasonable Lisp implementation (eq x x) is always true
> > (I was unable to find any normative statement saying this, but
> > othewise almost everything that standard says about evaluation
> > is meaningless).
>
> Not true. CLHS on EQ:
>
> An implementation is permitted to make ``copies'' of characters and
> numbers at any time. The effect is that Common Lisp makes no
> guarantee that eq is true even when both its arguments are ``the
> same thing'' if that thing is a character or number.
>
> A sketch of a reasonable implementation strategy that could result in
> (let ((x 1)) (eq x x)) evaluating to NIL:
>
> http://groups.google.com/group/comp.lang.lisp/msg/8767a6c7cf23286d
>
OK, I should have written 'eql'. But this does not not change the
main point.
--
Waldek Hebisch
·······@math.uni.wroc.pl
From: Raymond Toy (RT/EUS)
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <sxd7ihqgj07.fsf@rtp.ericsson.se>
>>>>> "Waldek" == Waldek Hebisch <·······@math.uni.wroc.pl> writes:
Waldek> Juho Snellman <······@iki.fi> wrote:
>> Waldek Hebisch <·······@math.uni.wroc.pl> writes:
>> > BTW: I do _not_ expect Ansi Lisp to fully conform to IEEE 754:
>> > IEEE says to if x is NaN (not a number) then x is not equal to x.
>> > But in a reasonable Lisp implementation (eq x x) is always true
>> > (I was unable to find any normative statement saying this, but
>> > othewise almost everything that standard says about evaluation
>> > is meaningless).
>>
>> Not true. CLHS on EQ:
>>
>> An implementation is permitted to make ``copies'' of characters and
>> numbers at any time. The effect is that Common Lisp makes no
>> guarantee that eq is true even when both its arguments are ``the
>> same thing'' if that thing is a character or number.
>>
>> A sketch of a reasonable implementation strategy that could result in
>> (let ((x 1)) (eq x x)) evaluating to NIL:
>>
>> http://groups.google.com/group/comp.lang.lisp/msg/8767a6c7cf23286d
>>
Waldek> OK, I should have written 'eql'. But this does not not change the
Waldek> main point.
Maybe you want to use =. eql means the bits are exactly the same,
roughly. But there are lots of different NaN bit patterns.
Ray
On Jan 30, 7:21 pm, Waldek Hebisch <·······@math.uni.wroc.pl> wrote:
> BTW: I do _not_ expect Ansi Lisp to fully conform to IEEE 754:
> IEEE says to if x is NaN (not a number) then x is not equal to x.
> But in a reasonable Lisp implementation (eq x x) is always true
> (I was unable to find any normative statement saying this, but
> othewise almost everything that standard says about evaluation
> is meaningless). Since beeing eq in Lisp implies beeing equal
> Lisp can not treat Nan-s in IEEE way. So either Lisp has to
> forbid Nan-s (which means only partial IEEE support, but is
> probably the best choice), or break Ansi rules, or break IEEE
> rules.
EQ and EQL are concerned with object identity, which is a concept that
isn't addressed by IEEE. If you use = to compare things, I would
expect IEEE semantics. The spec already hints in that direction by
specifying that (= 0.0 -0.0) => t
Given when it dates from, I think the lack of requiring IEEE floating
point semantics (and specifying how they work wrt a few parts of the
spec) is a shortcoming of the ANSI CL spec. That said, the market has
pretty well sorted this issue out, so it's only a relatively small
nit. ISLISP's approach of carefully excluding floating point numbers
from the spec, but in a way where it's obvious how and where to add
them, is interesting. It allows for conforming implementations for
super-constrained environments where there's no hardware floating
point, a niche situation which CL chooses to ignore.
From: Jeronimo Pellegrini
Subject: Re: Spartns (fast and flexible tensor representation for Common Lisp)
Date:
Message-ID: <fnm5ku$r90$1@aioe.org>
On 2008-01-28, Pascal Bourguignon <···@informatimago.com> wrote:
> You are testing the wrong thing!
>
>
> CLHS 2.3.2.2 says that:
>
> An implementation may provide one or more kinds of float that
> collectively make up the type float. The letters s, f, d, and l
> (or their respective uppercase equivalents) explicitly specify the
> use of the types short-float, single-float, double-float, and
> long-float, respectively.
>
>
> Note the very meaningfull "MAY" provide.
OK, I understand now.
I have disabled that assert in the library; maybe it was too strict and
not very friendly to the user.
Thanks Pascal for this clarification!
J.
You may want to have a look at LambdaTensor by Thomas Fischbacher.
The original webpage has disappeared, but the package seems
to be available from [1].
jan
[1] http://guests.mpim-bonn.mpg.de/moeller/