Yes, we are disagreeing only on the difference between unlikely and
asteroid-impact-unlikely.
L., L:, and S: present different problems. L: is straightforward, but
it reconstructs the whole boxing hierarchy even when only the leaves are
modified. L. searches every box, as mentioned earlier.
Ok, but it's not just L.
It's also L: and S:
Also, generally speaking, most applications mostly use a subset of
maybe a dozen J primitives (with different kinds of applications using
a different subset - for example, there's not a lot of call for
exponential functions when manipulating textual
The chicken-egg point is valid.
I'm saying something stronger: applications requiring high boxing levels do
not need L. enough to justify the overhead imposed on ordinary boxed arrays.
And stronger than that: even if an application is known to use heavy
boxing, the overhead of keeping the level
That's something of a chicken problem, isn't it?
We avoid inefficiencies in the implementation, therefore those aspects
of the implementation do not see much use.
That said, there are other issues here (developer time, especially).
But I'd prefer to think of this as an open issue which might be
Based on my scant usage of it, caching would t take more work than it's
worth.
Henry Rich
On Sun, Dec 17, 2023, 12:13 PM Raul Miller wrote:
> On Sun, Dec 17, 2023 at 11:50 AM Henry Rich wrote:
> > FYI: L. by itself is usually a mistake. It recurs through all boxing to
> > the bitter end.
On Sun, Dec 17, 2023 at 11:50 AM Henry Rich wrote:
> FYI: L. by itself is usually a mistake. It recurs through all boxing to
> the bitter end. Better to use (0 < L.) which allows early exit.
Hmm... at least on 64 bit architectures, it seems like L. would
frequently be worth caching (might need
That ^:L. is a good idea, one that I would have used a few times if I'd
thought of it.
FYI: L. by itself is usually a mistake. It recurs through all boxing to
the bitter end. Better to use (0 < L.) which allows early exit.
Henry Rich
On Sat, Dec 16, 2023, 7:36 PM Raul Miller wrote:
> I've
I've also used U^:L.L:1 when dealing with that kind of data structure
where I only wanted to act on the part that's deeply nested.
!L:0^:L.L:1 (<0 1 2),<2 4;3 5 7
┌─┬─┐
│0 1 2│┌┬──┐│
│ ││2 24│6 120 5040││
│ │└┴──┘│
└─┴─┘
I like L: a lot. You can do neat things:
! L: 0 (<0 1 2),<2 4;3 5 7
┌─┬─┐
│1 1 2│┌┬──┐│
│ ││2 24│6 120 5040││
│ │└┴──┘│
└─┴─┘
> On Dec 16, 2023, at 09:09, Henry Rich wrote:
>
> 'prefix' ,L:0 names
>
> Untested.
>
>
'prefix' ,L:0 names
Untested.
Henry Rich
On Sat, Dec 16, 2023, 10:31 AM 'Viktor Grigorov' via General <
gene...@jsoftware.com> wrote:
> The second boxing is unnecessary though.
>
>('prefix'&, &.>) q=:Aileen`Brittney`Gail`Fiona
>
> Also, alternatively
>
>([: <@;"1 (<'prefix')&,.) q
>
>
The second boxing is unnecessary though.
('prefix'&, &.>) q=:Aileen`Brittney`Gail`Fiona
Also, alternatively
([: <@;"1 (<'prefix')&,.) q
Dec 16, 2023, 16:03 by schott.br...@gmail.com:
> Robert, especially, but all,
>
> Your solution is great and exploring it took me to the NuVoc page for
Robert, especially, but all,
Your solution is great and exploring it took me to the NuVoc page for &. :
https://code.jsoftware.com/wiki/Vocabulary/ampdot .
There I first found the following solution and then below that, your
solution based on Semiduals .
(<'Mrs. ') ,&.> names
This seems like it would get more responses in the programming forum, but you
can also use gerund operands to &. and select which argument you want to
process.
names=:'Aileen';'Brittney';'Gail';'Fiona'
'Mrs. ' ,&.(a:`>) names
┌───┬─┬─┬──┐
│Mrs. Aileen│Mrs.
Try
(<'Mrs. ') ,&.> names
+---+-+-+--+
|Mrs. Aileen|Mrs. Brittney|Mrs. Gail|Mrs. Fiona|
+---+-+-+--+
Or, if you like avoiding parentheses
names ,~&.> <'Mrs. '
+---+-+-+--+
|Mrs.
names=:'Aileen';'Brittney';'Gail';'Fiona'
names
┌──┬┬┬─┐
│Aileen│Brittney│Gail│Fiona│
└──┴┴┴─┘
'Mrs. ' "0
I tried different approaches. I want to prefix 'Mrs.' to each name.
--
15 matches
Mail list logo
