> As far as I can understand the "revise" verb,  you don't need the
> adjacency matrix a, although it does help to have a 2-column matrix of
> index pairs.
>
> I think Raul has overlooked your use of the right argument ys within that
> verb,  though he's right about selecting with it. Here's a derivation of
> arcs without explicit recourse to the adjacency matrix  (I've just noticed
> that Raul presents a similar idiom):
>
>         arcs=. ys  (]#~ (e.~ {."1))   ($#: I.@,)  *|:A
>
> I. returns a vector of indices to the ravelled boolean;  $ #: turns them
> into a matrix of pairs of indices to an array of the shape of |:A.
>
> (]#~ (e.~ {."1)) selects those arcs with an element of ys as the from-node
> (or perhaps they're the to-nodes?)
>

This is a marvel of engineering to be sure ;-).  It took me quite some time
to figure out #: (which require figuring out #. (which required figuring
out /.)).  Wow.  #. and #: seem useful and the fact that you can list
different bases as the left argument is blowing my mind a little bit.  I
did trace through and understand what's meant.  Nice.

|: is not needed since *A should always be symmetric matrix.  If a
constraint between x and y is symmetric, then Axy = Ayx, otherwise Axy is
the index of the transpose constraint at index Ayx.

I'm not sure if we want to remove the adjacency list 'a' in the end
though.  'A' may be sparse and having 'a' should speed up computation (?).
In my long standing csp problem I have an 'A' that has dimensions 256x256
but each variable has at most 4 neighbors.

This form renders the arcs array already sorted,  but note that if you do
> need to sort the elements of an array,  it's sufficient to use the idiom
>  /: ~    (rather than ({~ /:)   .     Presumably sorting "arcs" is merely a
> matter of taste.
>

Yes, sorting is unnecessary.  It was brought over from a previous version
of the code from which the current version was distilled.  I lacked the
cojones to throw it out.  This just shows that public dissection is nice to
force these choices.  =)  The J code is serving as prototype for some
OpenCL code and I'm not sure how nicely things will play out there (ie. it
may be better to have the locality of having the arcs sorted).  I've
removed the sorting.


>
> It's quite nice to be able to input several components of an argument by
> (local) name with
>    'A a C'=.x
>    'ys D'=. y
> rather than
>     A=. > 0{x
>     a=. > 1{x
>     ys=. > 0{y
>     D=.  > 1{y
>

Great, thank you, I was looking for something like this.


> I also wonder whether your example will still work if there are binary
> constraints involving variables (say z and t) indexed with 2 or 3.  And
> what happens if there are more than one binary constraints on a pair of
> variables?  eg,  X+Y=4 AND X>Y ?
>

Haven't tried having more than two constraints, indexed with 2, 3 etc., but
it should work.

If you want to have two constraints (X+Y=4 AND X>Y) in the current scheme
you need to make a new entry in C with the and of both of them.


>
> I'd have been very pleased with myself if I'd come up with code as good as
> this when I started J - would be pretty pleased if I managed it now!
>
>
Thanks =)

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

Reply via email to