[plt-dev] flvector

Since 4.ss in srfi is nothing other than:

(require (matching-identifiers-in #px"\\b_?[suf](8|16|32|64)vector\\b"
                                  scheme/foreign))
(provide (all-from-out scheme/foreign))

I assume just requiring SRFI 4 is negligible overhead and I might as well
just use it.

Doug

On Fri, Dec 18, 2009 at 11:45 AM, Robby Findler <robby at eecs.northwestern.edu
> wrote:

> The two different -> s are really different things, so when you have
> both of them in a single file you need to do something to distinguish
> between them. I think that in this case, probably the best thing is to
> prefix the foreign imports with, say, f:.
>
> Robby
>
> On Fri, Dec 18, 2009 at 12:42 PM, Doug Williams
> <m.douglas.williams at gmail.com> wrote:
> > I just tried removing my dependency on SRFI 4 by using the scheme/foreign
> > module (which also defines them). However, when I require the
> scheme/foreign
> > module, I have a problem. It has the following snippet of code:
> >
> > (provide ->) ; to signal better errors when trying to use this with
> > contracts
> > (define-syntax ->
> >   (syntax-id-rules ()
> >     [_ (raise-syntax-error '-> "should be used only in a _fun
> context")]))
> >
> > So, my function contracts in the requiring module now give an error.
> >
> > I've never used the FFI interface, but I can see that it uses -> as part
> of
> > the syntax for defining foreign functions. But, the comment "to signal
> > better errors when trying to use this with contracts" would imply it is
> > supposed to help me somehow, not disallow the use of function contracts
> with
> > something that requires scheme/foreign. Am I missing something?
> >
> >
> > On Fri, Dec 18, 2009 at 10:02 AM, Doug Williams
> > <m.douglas.williams at gmail.com> wrote:
> >>
> >> Matthew,
> >>
> >> Attached is a zip file with some homogeneous vector and array code I was
> >> working on in the past. The code in vtype.ss abstracts the definitions
> of
> >> the various SFRI 4 vector types (and regular Scheme vectors). The vector
> >> types it knows about are object (i.e., straight Scheme heterogeneous
> >> vectors), u(8,16,32,64), s(8,16,32,64), and f(32,64). There are also
> complex
> >> vectors of the numeric types cu(8,16,32,64), cs(8,16,32,64), and
> cf(32,64).
> >> The code in type-vector.ss abstracts the vector types describes in
> vtype.ss
> >> into a single typed-vector type. The code in array.ss provides the array
> >> abstraction with the underlying data stored as a typed-vector. Finally,
> the
> >> array-test.ss test the array abstraction. [Just running array-test.ss
> will
> >> give you a pretty good idea about the array abstraction.]
> >>
> >> The intent is to provide a homogeneous array implementation similar to
> the
> >> underlying arrays in Matlab (or numpy in Python). This is what I would
> like
> >> to make more efficient and better integrated into the rest of PLT
> Scheme.
> >>
> >> So, I guess the questions are:
> >>
> >> 1) Should I skip SRFI 4 altogether? The SRFI 4 implementation just
> exports
> >> things from scheme/foreign, so it would probably make sense to go
> straight
> >> to it. But, I am also using the naming convention from SRFI 4.
> >>
> >> 2) How would array slicing best look syntactically? I have a simple
> >> slicing capability there now so you can see what it looks like. But
> >> basically, for any dimension, you can specify a list (start end step)
> and
> >> any element can be wildcarded using * - also, the whole dimension can be
> >> wildcarded. Efficient slicing (e.g., no copying required) is an
> important
> >> element of the design.
> >>
> >> 3) How would we best tie it to the rest og PLT Scheme? In particular, it
> >> would be nice to have efficient implementations of the various for
> routines
> >> that just strided through the underlying vector efficiently. But, I
> think
> >> that will require knowledge of the underlying vector type. etc and might
> be
> >> a lot of work.
> >>
> >> So, I think getting a really efficient implementation would require
> >> significant coordination with the PLT developers. My long-term goal (as
> >> you've probably heard me say before) is to get a Matlab-like (or
> >> Matlab-lite) analysis capability.
> >>
> >> Any thoughts?
> >>
> >> Doug
> >>
> >> On Fri, Dec 18, 2009 at 8:41 AM, Matthew Flatt <mflatt at cs.utah.edu>
> wrote:
> >>>
> >>> In case anyone is already using the `flvector' operations, they've
> >>> moved to a new `scheme/flonum' library.
> >>>
> >>> (I'm preparing a post about `scheme/flonum' for the plt-scheme list.)
> >>>
> >>>
> >>>
> >>> _________________________________________________
> >>>  For list-related administrative tasks:
> >>>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
> >>
> >
> >
> > _________________________________________________
> >  For list-related administrative tasks:
> >  http://list.cs.brown.edu/mailman/listinfo/plt-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091218/7f9da90d/attachment.html>