Forgot for a moment the main reason for {::: proposal.
Parsing rules allow for 1{::: as 2 separate tokens
They dont allow for 1Y. or (1i. for that matter)
On Monday, March 2, 2020, 06:15:08 p.m. EST, Raul Miller
wrote:
X. and Y. require shift keys on my keyboard.
Meanwhile, as a gener
The lr of (`(<(":0);_)) (`:6) should be itself.
in addition to Jose's a2 bug (`_) which does not produce the atomic
representation of _ when executed, there is also
(<'0';3)`
<'0';3` (here ` binds with 3, and not the entire expression to the left of `)
There is no bug for `(<'0';3)
What is
I tried on my debian but the shared library had some dependency
issue and couldn't run.
The api of 1.7 and 1.8 were different. I don't know if
that of 1.8 and 1.9 are the same or not. I couldn't test.
Tue, 03 Mar 2020, Ben Gorte написал(а):
> > I think the addon needs update, the old version of
> I think the addon needs update, the old version of libflann it used is no
> longer available on linux.
That's the easy part. In flann.ijs, where it says libflann.so.1.8, change
the 8 into a 9. Seems to be compatible.
VERSION7 should be 0 .
Furthermore, the sentences with cd have to be modified
What I read here is complaining. What I am asking for is a suggestion
for action. What should be changed, and how, to make the system you want?
Henry Rich
On 3/2/2020 9:51 PM, Jose Mario Quintana wrote:
The issue, to me, is not reflected in your example (wherein that context
makes sense to r
The issue, to me, is not reflected in your example (wherein that context
makes sense to replace the AR). Consider instead the following adverb,
a2=. (`(<(":0);_)) (`:6)
a2
(`_)(`:6)
(5!:5)<'a2'
(`_)(`:6)
The issue, in this context, is that,
b2=. (`_)(`:6) NB. defined using the LR
I think the addon needs update, the old version of libflann it used is no
longer available on linux.
On Tue, Mar 3, 2020, 2:59 AM 'Michael Day' via Programming <
programm...@jsoftware.com> wrote:
> Was this addon not available for Windows installations?
>
> I don't see it under my J901, nor J807
I am trying to follow this to see if there is a bug that needs fixing.
That has not been made clear to me. I observe
(f@g)`h`]
+-+-+-+
|+-+-+|h|]|
||@|+-+-+|| | |
|| ||f|g||| | |
|| |+-+-+|| | |
|+-+-+| | |
+-+-+-+
(f@g)`h`] `: 6
+---+-+-+
|+-+-+-+|h|]|
||f|@
> Any definition of gerunds limited to atomic representations of verbs is
an oversimplification (for natural language gramatical analogy). It should
be atomic representations without limitations. @. and `:6 can produce nouns
and modifiers from their atomic representations.
I fully agree with you
X. and Y. require shift keys on my keyboard.
Meanwhile, as a general rule, if things have gotten to be complicated
enough that you need boxed arguments for a dyad, it's pushing things
to refer to the contents of those boxes numerically.
I mean, certainly, I've done that -- but I prefer other appr
Sometimes it does an initial extra iteration. It does so in this case.
I might work on eliminating the extra iteration. Someday.
Henry Rich
On 3/2/2020 6:10 PM, Raul Miller wrote:
I think he's asking why there's a second iteration.
Or, more specifically, why, when n is a list in u^:n why
I think he's asking why there's a second iteration.
Or, more specifically, why, when n is a list in u^:n why there is an
extra evaluation of u.
Thanks,
--
Raul
On Mon, Mar 2, 2020 at 6:04 PM Devon McCormick wrote:
>
> Because the 2nd iteration has HUMBLE -: 2 3 5 7 for which the result of
> "
X. and Y. require no shift keys :)
J is a language where functions that require more than 2 arguments, must pack
these arguments into lists or boxes.
On Monday, March 2, 2020, 03:22:12 p.m. EST, Raul Miller
wrote:
X: and Y: would probably be more readable. And, sure, that would need
Because the 2nd iteration has HUMBLE -: 2 3 5 7 for which the result of
"next" is 2.
smoutput HUMBLE [ smoutput next '' [ reset ''
1
2 3 5 7
smoutput HUMBLE [ smoutput next ''
2
3 5 7 4 6 10 14
On Mon, Mar 2, 2020 at 5:07 PM David Lambert wrote:
> Why is the last number in this post 2 in
Why is the last number in this post 2 instead of 1 please?
FACTORS=: p: i. 4
HUMBLE=: 1
next=: 3 : 0
result=. <./ HUMBLE
i=. HUMBLE i. result
HUMBLE=: ~. (((i&{.) , (>:i)&}.) HUMBLE) , result * FACTORS
result
)
reset=: 3 :'0 $ HUMBLE=: 1'
next reset''
1
http://www.jsoftware.com/forums
X: and Y: would probably be more readable. And, sure, that would need
a space in typical cases.
That said, personally, I'm not particularly fond of working with boxed
lists in tacit dyads.
Thanks,
--
Raul
On Mon, Mar 2, 2020 at 3:13 PM 'Pascal Jasmin' via Programming
wrote:
>
> consider the a
consider the adverbs
X =: (&({::))(@:[)
Y =: (&({::))(@:])
These are useful for extracting an item from either x or y parameter lists
(that may be boxed) tacitly
2 Y i.3 equivalent to (2 {:: ]) i.3
shorter and doesn't require parentheses if not the right most part of a fork.
I'd propose {:::
Was this addon not available for Windows installations?
I don't see it under my J901, nor J807, nor my remnants of 806 or 805.
Google suggests it's for nearest neighbours - though there doesn't seem to
be anything helpful arising from searching for "flann" in the J Wiki.
Cheers,
Mike
On 02
Henry,
Your solution indeed works as advertised.
Thanks so much!
Raoul
--
For information about J forums see http://www.jsoftware.com/forums.htm
('early return' [ 1&Z:@1)^:(test_for_early_return) normal_return_value
untested.
Henry Rich
On 3/2/2020 8:55 AM, Raoul Schorer wrote:
Dear all,
I would like to know how to return from a fold, yielding a value that
does not depend on the underlying sequence.
Example:
0 (4 : '(x+y)') F:. ]
Dear all,
I would like to know how to return from a fold, yielding a value that
does not depend on the underlying sequence.
Example:
0 (4 : '(x+y)') F:. ] i. 5
yields '0 1 3 6 10'
using
0 (4 : '(x+y)[(_2 Z: 3=x)') F:. ] i. 5
stops the fold and returns '0 1 3'
But I do not understand if/h
21 matches
Mail list logo
