Suppose that ~. (and perhaps some relatives) can be implemented much more
efficiently if no guarantee is made about the order of the result. Is it
too much of an abuse of notation to use ({~?~@#)@~. as a special
combination to invoke such an algorithm? If so, what would be better?
Most speci
On Sat, Apr 9, 2022 at 4:04 AM Elijah Stone wrote:
> Suppose that ~. (and perhaps some relatives) can be implemented much more
> efficiently if no guarantee is made about the order of the result. Is it
> too much of an abuse of notation to use ({~?~@#)@~. as a special
> combination to invoke such
On Sat, 9 Apr 2022, Raul Miller wrote:
People will say that certain algorithms, such as hashing, are highly
efficient. But these assertions are quite often not accompanied by
adequate benchmarking on large datasets. And, these approaches often
have inefficient worst case behavior.
Hashing i
I would favor ~.!.1. No mnemonic value, but less likely to be forgotten.
What is your fast algorithm?
Henry Rich
On 4/9/2022 4:03 AM, Elijah Stone wrote:
Suppose that ~. (and perhaps some relatives) can be implemented much
more efficiently if no guarantee is made about the order of the
resul
On Sat, Apr 9, 2022 at 5:27 AM Elijah Stone wrote:
> Hashing is O(1) (or, if you prefer, O(#y) for ~.y, same as sorting). A
> sufficiently smart(tm) hash function will avoid inordinate collision
> rates, so I am not sure what worst case behaviour you are referring to.
Collision rates are indeed
The 904 beta cycle has started!
https://code.jsoftware.com/wiki/System/Installation/J904
Install it now to get a head start on exciting new stuff.
--
For information about J forums see http://www.jsoftware.com/forums.htm
The big news in J904 is multithreading. J verbs can now be run in
different cores, sharing the J global namespaces.
[A version of J with limited support for multithreading was revealed
last year by John Ference of Monument AI. John's work was an important
proof of concept, but the J904 versi
If ~.!.1 is used, then how would we denote a -. operating on sorted
arguments?
I build the hash table concurrently, using a multiprocessor; this means
the elements are processed out of order. Two ways of proceeding, not yet
sure which is better. The first is for each thread to accumulate the
I'm with Raul on this. A hashtable is a fine idea when memory is fast,
but if the hashtable greatly exceeds D3$ every hash lookup will be a
page miss which is hideous. A merge sort would look pretty good then.
Henry Rich
On 4/9/2022 3:23 PM, Elijah Stone wrote:
If ~.!.1 is used, then how wou
With multiprocessors, the calculus changes. Sort is still O(n) (I think
it can be O(lgn), but with bad constant factors), but hashing is O(1).
And there are interesting cases where you do have n processors (hpc,
gpgpu). In effect, once you have enough processors, they serve to hide
the latenc
Here is some odd behaviour I encountered while trying to induce a race
condition:
{{0 T.''}} :: ] ^:_''
14
t=: 1e9$0
f=. {{''[echo 7!:2't=: >:t'}}t.''
''[ >f"0]15$0
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
858993558
That looks like something amiss with the 7!:2 report. Space usage for a
thread should be inited to 0.
15 threads because there had to be some limit (JE internal needs) and 15
seemed like a lot.
When there are no more idle threads, the master thread executes in its
own thread. The timing o
On Sat, 9 Apr 2022, Henry Rich wrote:
That looks like something amiss with the 7!:2 report. Space usage for a
thread should be inited to 0.
it's measuring the space taken by t=: >:t
15 threads because there had to be some limit (JE internal needs) and 15
seemed like a lot.
I have 48. HP
If I understand correctly,
{{for. 1 2 3 4 -.2 T.'' do.0 T.'' end.}}0
each=: (t.'')every
should "just work". The performance of code using 'each' may change
but the results should match current results.
So far, in my limited tests, this has indeed been the case.
Thanks,
On Sat, Apr 9, 202
On Sat, Apr 9, 2022 at 6:26 PM Henry Rich wrote:
> 15 threads because there had to be some limit (JE internal needs) and 15
> seemed like a lot.
https://bizon-tech.com/amd-epyc-7000-series-up-to-128-cores-workstation-pc
FYI,
--
Raul
-
A worklist is an option. That's why there's a spare parameter.
Henry Rich
On 4/9/2022 6:38 PM, Elijah Stone wrote:
On Sat, 9 Apr 2022, Henry Rich wrote:
That looks like something amiss with the 7!:2 report. Space usage
for a thread should be inited to 0.
it's measuring the space taken by
On Sat, Apr 9, 2022 at 5:58 PM Elijah Stone wrote:
> 1. If the second invocation triggers the oom killer, why does not the
> first? Leak?
The oom killer is troubling. As would be similar mechanisms.
For now, it's an issue that J can be shut down with no hint as to why.
Thanks,
--
Raul
--
Yes, we will have to develop ways to avoid memory overusage.
Henry Rich
On 4/9/2022 7:40 PM, Raul Miller wrote:
On Sat, Apr 9, 2022 at 5:58 PM Elijah Stone wrote:
1. If the second invocation triggers the oom killer, why does not the
first? Leak?
The oom killer is troubling. As would be simi
On Sat, 9 Apr 2022, Raul Miller wrote:
For now, it's an issue that J can be shut down with no hint as to why.
This is arguably a flaw in linux, not in je. That said, there is mlock(2).
--
For information about J forums see ht
On Sat, Apr 9, 2022 at 7:59 PM Elijah Stone wrote:
> On Sat, 9 Apr 2022, Raul Miller wrote:
>
> > For now, it's an issue that J can be shut down with no hint as to why.
>
> This is arguably a flaw in linux, not in je. That said, there is mlock(2).
My redefinition of each, in the context of some
On Sat, 9 Apr 2022, Raul Miller wrote:
My redefinition of each, in the context of some (rather messy) code I
have been running under Windows, shut down J for me. Reverting to the
original definition of each allowed me to run it to completion under
j9.04.
I see, that definitely sounds like a
If you can give an example I'll look into it.
Henry Rich
On 4/9/2022 8:01 PM, Raul Miller wrote:
On Sat, Apr 9, 2022 at 7:59 PM Elijah Stone wrote:
On Sat, 9 Apr 2022, Raul Miller wrote:
For now, it's an issue that J can be shut down with no hint as to why.
This is arguably a flaw in linux
22 matches
Mail list logo
