[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] arrays
From: |
Vanuxem Grégory |
Subject: |
Re: [Gcl-devel] arrays |
Date: |
Tue, 06 Sep 2005 14:30:58 +0200 |
Le lundi 05 septembre 2005 à 13:42 +0200, Vanuxem Grégory a écrit :
> Le dimanche 04 septembre 2005 à 23:38 -0400, Camm Maguire a écrit :
> > Greetings!
> >
> > What is '(array nil) suposed to mean?
> >
> > I noticed that cmucl has support for 1 2 4 8 16 and 32bit array
> > integers. GCL has 1, 8, 16 and 32 (on 32bit machines).
>
> Is it possible to send a 32 bits static array to cline ?
>
> I have stopped my lapack implementation, since on my 64 bits machine,
> arrays of int are array of long (8 bytes), and this will probably not
> change in the future.
And if i use (on a 64 bit arch) :
(setq a (make-array '(5 5) :element-type 'long-float :static t))
(setq ipiv (make-array 5 :element-type '(signed-byte 32) :static t))
#(0 0 0 0 0)
>(dgetrf 5 5 a 5 ipiv)
1
>ipiv
#(8589934593 17179869187 5 0 0)
^^^^^^^^^ ^^^^^^^^^^^
the array contains '(signed-byte 64) even if that don't exist.
Cheers,
Greg
> >
> > 1) Is there any real benefit to 2 and 4 bit integer types, considering
> > the access overhead vs space tradeoff?
> > 2) My understanding is that the simple (signed-byte
> > 2^n),(unsigned-byte 2^n) strategy will not pass all Paul's tests,
> > as upgraded-array-element-type must preserve subtypep relationships
> > -- one needs at least (unsigned-byte 2^n-1), etc.
> > I.e. non-negative-char, signed-char, and (optionally) (unsigned
> > char) for each size type. This is what I've implemented at
> > present, and I'm passing all relevant tests. I'd obviously like to
> > support the minimum number of types possible, if for no other
> > reason than it slows down subtypep et. al. on (array *).
> >
> > Take care,
> >
>
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
>