I would also suggest Iverson's "J" - a generalization of the
operators in APL (along with an ASCII keyboard syntax!)

http://www.jsoftware.com/

Interesting to see so many former APL'ers around here... Wasn't
Kent Beck also doing something in Smalltalk to program Massively
Parallel Processors? (Goodyear's MPP?)

Dieter.


Stephane Ducasse wrote:
> 
> Hi david
> 
> have you looked at F-script, it has a APL way of dealing with
> collections of objects. I'm sure
> that this is not what you where referring to but this is interesting.
> Epscially because the author of F-script told that contrary to what I
> was thinking he can do some
> good optimization.
> 
> Stef
> On vendredi, décembre 6, 2002, at 10:32  pm, David A. Smith wrote:
> 
> > Actually, the graphics chip manufacturers are moving in the direction
> > of general purpose massively parallel hardware. One of the goals of
> > our project is to tap into that kind of potential to go beyond
> > graphics computation. The VPU access is a start, but to be honest, the
> > real win will come later on. Our matrix extension is intended to add
> > similar general purpose capabilities to those available in APL, with
> > real performance. This kind of capability is not just needed for 3D
> > graphics, but for any kind of serious scientific simulation.
> >
> > Regards,
> >
> > David
> >
> >
> > At 12:03 PM 12/6/2002 +0100, you wrote:
> >> On Fri, 6 Dec 2002, Joshua D Boyd wrote:
> >>
> >> > On Thu, Dec 05, 2002 at 03:03:08AM -0500, Joshua 'Schwa' Gargus
> >> wrote:
> >> >
> >> > > Tell me more!  Arbitrary n-D matrix operations will be hardware
> >> > > accelerated, yet accessed through a nice (extended) Smalltalk
> >> > > interface?  Cool!
> >>
> >> Actually I think David was referring to Vector Processing Units. This
> >> is
> >> AltiVec on PowerPC, MMX/SSE on Intel, 3DNow! on AMD, etc (?). So the
> >> discussion goes a little bit in the wrong direction, but it's
> >> interesting
> >> still ;-)
> >>
> >> > > I understand that consumer graphics cards generally have bad
> >> > > performance when it comes to reading data back from the card (ie:
> >> > > glReadPixels).  Has/will this changed with the latest hardware
> >> (Radeon
> >> > > 9700 and NV30)?
> >>
> >> Not fundamentally, I think.
> >>
> >> > >  Could you give a general idea of the bandwidth
> >> > > available?  The reason I ask is that I can imagine speeding up
> >> things
> >> > > like genetic algorithms.  Ideally, the objective function could be
> >> > > compiled to run on the graphics hardware, but realistically it
> >> would
> >> > > probably often require the CPU (please tell me I'm wrong).  In
> >> this
> >> > > case, bandwidth from the VPU to the CPU becomes important.
> >>
> >> As I said, VPU means the on-processor vector units. Generally the
> >> graphics
> >> processor is referred to as "GPU". Only recently some companies
> >> (3Dlabs,
> >> ATI) have begun to name their boards "Visual Processing Units",
> >> probably
> >> to distinguish them from NVIDIA, and causing confusion with this.
> >>
> >> > I've had good luck with reading vertexs and matrices back from
> >> Geforce3
> >> > and Quadro4 cards.  Never tried using glReadPixels.
> >>
> >> Graphics boards are optimized for getting data _to_ the screen, not
> >> back.
> >> In fact, there are "pure" modes where your application promises the
> >> graphics subsystem to never ever read back any state, which allows the
> >> driver to much more aggressively optimize its internal processing.
> >>
> >> OTOH, newer drivers have considerably sped up read-back rate for
> >> recent
> >> NVIDIA boards. It's just that hardware vendors put much more effort
> >> into
> >> optimizing the common pathes first. If you really need fast read-back
> >> capabilities you have to look in the professional market - one (if
> >> not the
> >> only) selling point of SGI machines today is _bandwidth_.
> >>
> >> > It used to be that the trick of getting good graphics out of a
> >> Indigo2
> >> > Impact was to push as much work onto the graphics subsystem, and
> >> > surprisingly, cache some of the state of the graphics subsystem to
> >> > minimize the number of glEnables and glDisables called.  I can't say
> >> > that this is really the best thing to do these days.
> >>
> >> It still is.
> >>
> >> -- Bert
> >
> >
> >
> Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch)
> http://www.iam.unibe.ch/~ducasse/
>   "if you knew today was your last day on earth, what would you do
>   different? ... especially if, by doing something different, today
>   might not be your last day on earth" Calvin&Hobbes

--
Dieter H. Zebbedies (dee'-trr  ayech  zeb'-ed-eez), E-mail: dhz at zh.com
Zebb-Hoff Machine Tool, 9535 Clinton Rd, Cleveland OH, 44144
 Design & CNC Manufacturing - Molds, Prototypes, Tooling, Fixtures
 Info: http://www.zh.com  Phone: +216 631 6100