Oops, I inadvertently left out the definition of Cmn. (Odd.. I thought
I remembered copying that into my message.)
Anyways, it was really basic;
Cmn=: 2 :'m+n'
Thanks,
--
Raul
On Mon, Feb 17, 2020 at 11:18 AM Raul Miller wrote:
>
> So here's the deal with Henry's point 3:
>
>Cxmny=: 2
So here's the deal with Henry's point 3:
Cxmny=: 2 :'x+m+n+y'
(>: i.3) Cxmny (*:9)
(1 2 3) (2 : (':'; 'x+m+n+y')) 81
Here, m .and n have been evaluated, but are represented as nouns, not
as text. You see a formatted representation but the internal
representation is binary
(>: i.3) Cmn (
All my fault :/
In the sentence that didn’t behave as expected,
I used a variant of my conjunction that actually
wasn’t defined tacitly: there were references to y
which kept m and n (and thus constant expressions
they were occurring in) from being evaluated when
the derived verb was built.
Sorry
Let us start with your verb example but with some specific values,
X=. 0 1 2
( test=. (>: X) {~ ] )
1 2 3 {~ ]
as you mentioned, the result of (>: X) becomes the left tine of the fork
that defines the resulting verb,
type'test'
┌┐
│verb│
└┘
which, presumably is meant to be use
Several misconceptions.
If the body of c refers to y, m c n produces a verb that operates on a
subsequently-given [x]/y. I will assume that is what you are using,
since the only way to produce a modifier is using an explicit definition.
In this case, you must distinguish between the executio
Sorry, I thought I had done it tacitly
but your examples seem to prove me wrong.
(Maybe I didn’t understand the concept
of “semi-tacit” and where it applies.)
Of course we want to have late binding
available but there are also cases when
early binding is preferred.
My confusion is due to a senten
this all behaves correctly (did not understand your initial post)
"N
"1
+/"N
+/"1
(2 : 'u"v y')N
2 : 'u"v y'1
3(2 : 'u"v y')N
3 (2 : 'u"v y') 1
3 (2 : 'u"v y') 1
(3) (2 : 'u"v y') 1
3(2 : 'u"v y')N
(3) (2 : 'u"v y') 1
M =: 3
M(2 : 'u"v y')N
(3) (2 : 'u"v y') 1
What you are actually
I don’t have any concrete example that’s actually
expensive in terms of time or space (where space
means “memory”) but in place of >: in the verb
example, there could be any function, it could
take hours. This is no less true for conjunctions.
And I don’t want this to be called each and every
time
Why do you think there will be major savings of
computational resources? Can you give a concrete
example?
Sun, 16 Feb 2020, Hauke Rehr написал(а):
> Hello everybody,
>
> I recently stumbled upon some at least
> for me counterintuitive (read: puzzling) behaviour:
>
> In a verb like (>: X) {~ ], w
Hello everybody,
I recently stumbled upon some at least
for me counterintuitive (read: puzzling) behaviour:
In a verb like (>: X) {~ ], when X is a defined constant,
the constant expression (>: X) is substituted in the verb (as expected)
but in a conjunction M c N, when M and N are defined const
10 matches
Mail list logo
