[UV=:0,(,-@|.)=i.3
0 0 0
1 0 0
0 1 0
0 0 1
0 0 _1
0 _1 0
_1 0 0
foo=: {{ x+ y{UV }}NB. constructed conform the diagram on
https://code.jsoftware.com/wiki/Vocabulary/fcap
$0 0 0 (]F:. foo) 3 2 _3
3 3 3 3 3
$0 0 0 (]F:. foo)~ 3 2 _3
3 3 3 3 3
foo=: {{ y+ x{UV }}
I thought that I had searched for roundNums on that page and not found
a definition.
That said, I see it now,
That said, it's used on that page before it's defined.
That said, now that I have it defined, I am getting a value error on
stepsftn which I see referenced 10 times on that page (but no
"roundNums" is the last definition on the page. Did you copy the whole
thing?
On Mon, Sep 6, 2021 at 9:41 PM Raul Miller wrote:
> I get a value error on roundNums when I try loading that script.
>
> For a black and white (and shades of gray) palette, I guess I like 0 0
> 0,:255
>
> Thanks,
>
I get a value error on roundNums when I try loading that script.
For a black and white (and shades of gray) palette, I guess I like 0 0 0,:255
Thanks,
--
Raul
On Mon, Sep 6, 2021 at 8:33 PM Devon McCormick wrote:
>
> There are a number of palettes I have found useful here:
> https://code.jso
There are a number of palettes I have found useful here:
https://code.jsoftware.com/wiki/User:Devon_McCormick/Palettes .
On Mon, Sep 6, 2021 at 3:16 PM Raul Miller wrote:
> I was poking through the viewmat code, and noticed a couple things
> that might be of interest.
>
> First, is that viewmat
I was poking through the viewmat code, and noticed a couple things
that might be of interest.
First, is that viewmat has a default palette, which you can see here:
load'viewmat'
viewmat i.6
Viewmat uses linear interpolation between the palette colors to
represent position in the range of v
Hmm... poking at this with your original data, I do see an issue --
the groups aren't quite long enough.
Also, I should note that my earlier suggestion of ndx {each ORPnoid
does not work -- there, 'each' should be replaced by 'L:0'
Anyways, the result is still useful, but to get the grouping tha
Execution time is going to depend on how big the groups are.
That said, I *do* make mistakes at times, and it's good practice to
test and manually verify against a small sample.
Anyways, good luck,
--
Raul
On Mon, Sep 6, 2021 at 12:13 PM Pablo Landherr wrote:
>
> This appears to work! I'm ext
This appears to work! I'm extremely impressed. Truly awesome. Execution
time is unknown at this point as it's been running for a while without
completing yet. :-)
After all, there are literally billions of comparisons being done by i.
(Should have used a subset first to verify, but I was so keen
I should also note that gmail decided that part of the code was not
code but a part of the previous reply.
Here's a version which hopefully works around that issue:
cnGroupIndices=:{{
NB. x: ORPnoid
NB. y: ORPioid
assert. 1=>./x#/.y
valid=. y e. x
cns=. (1+x i.valid#y) (1+I.valid)} i.1+
Oh... I didn't think this through. Not all of these values are connected.
I should also verify an assumption: that connections occur when a
value in ORPnoid matches a value in ORPioid (and vice versa). If this
assumption is invalid, then this won't be a useful result.
Anyways, here's a fixed vers
Unfortunately, it fails. Given time I might realize the problem but I
suspect it's obvious to sharper minds than mine.
#x=: ORPnoid
31636439
#y=: ORPioid
31636439
1=>./x#/.y
1
#cns=. (1+x i.y) (1+i.#x)} i.1+#x NB. connections
31636440
r=: ( wrote:
> Ok..
>
> So we can use indices into ORP
Ok..
So we can use indices into ORPnoid to uniquely identify each relevant
connection, and then use Michal Wallace's algorithm. (This means that
in our connection list, we'll add 1 to each of those indexes, since
that's what we had working.)
In other words, I think that this should work:
cnGroup
Raul,
True to form, your approach might offer a way forward. To add some details
to the actual case:
#ORPnoid
31636439
#ORPioid
31636439
#ORPioid -. ORPnoid NB. some ioid do not connect to any other
563228
10{.ORPioid NB. the original data is hex in character form, but I convert
it to symbol
If you get 1 from either
>./ NID #/.OID
or
>/. OID #/. NID
then you can represent the connection matrix with a connection list,
which would be about the same size as your OID or NID list.
I hope this makes sense,
--
Raul
On Mon, Sep 6, 2021 at 3:53 AM Pablo Landherr wrote:
>
> Thank
Thank you for your clever solutions. Unfortunately I underestimated the
problem of the size of the data I'm processing. As nid and oid of my test
data each have a tally of 3.16e7, the connection matrix of my data contains
1e15 bits, which naturally gives me a limit error. I'll have to chew
through
16 matches
Mail list logo
