Ahmad Issa wrote:
> I don't quite have the money to get the book (i'm still in
> highschool), i'd really appreciate it if you could write some
> code that i can study.

Code that you can study... hmm...

First off, a lot of what your verb 'next' is doing could be
accomplished using a phrase like (M +/ .* ]) where M is chosen
to fit what you are trying to do.

You can get an idea of what M would look like with |:next"1=i.7

But this is only approximate, because you are doing some things
in next which would take another step to complete.

Example:
  (|:next"1=i.7)+/ .*i.7
or
  M=:|:next"1=i.7
  M+/ .*i.7
vs.
  next i.7

The elements of the result which are not treated correctly
here come from (1&{ + +:@:(*/)@:(2 3&{)) and >:@:(6&{)

Perhaps the easiest way of dealing with >:@:(6&{) would be
to add another element to the list which is always 1.  Then
this element could be added to the result using +/ .*

The product 2*2&{*3&{ requires a bit more thought.  Perhaps
it could be achieved introducing more constant elements
(I think you'd need a 2), and an expression of the
form M +/ .* y */ .^ N where M and N are carefully chosen
constants -- N would be a boolean array which selects the
desirable products (basically it's just an identity matrix
except that you'd also provide a row to get the product
you're after).  But I'd have to test that out to see whether
the speed of */ .^ is acceptable.

Caution: the above does not address your code, overall, just
the 'next' verb.  It's not really a recommendation about
the right way to approach this problem -- it's only intended
to provide some code you might find interesting.  I believe
that Devon McCormick's post shows a much better way to
approach your problem.

As a further note: it would be interesting to compare the
performance of machine language implementations designed using
the style of your original post and code designed using the
style I'm suggesting here.  In terms of "minimal data movement",
your code might have some advantages, but with the design of
processor caches, that might not be the case (or might still
be the case).

-- 
Raul


----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to