Well explained! What you say makes perfect sense. Now, what can we do
to help people stop doing that?
Abstractly, specifying rank u"n is simply an instruction to JE to chop
up the arguments into pieces of rank(s) n before applying u. For general
u, JE does exactly that. Thus "n is a directive to execute a certain
loop. It is not merely informational.
[Implicitly, every verb has a rank. Presented with an argument larger
than its verb rank, the verb will chop up its arguments.]
The implementation problem is that executing a verb u has a certain
overhead because of the nature of interpreters: arguments have different
types, results have types and shapes, they all have to coexist: starting
u and assimilating its result takes a few dozen clock cycles. If u
executes on one lousy atom, it's finished in 1 clock cycle, and almost
all the CPU time is spent in overhead.
The solution to this problem is Integrated Rank Support (IRS). When a
verb supports IRS, it warrants to JE that it will take care of a rank if
given. JE will skip the chopping-up step, trusting the verb to create
the right result. All the usual arithmetic verbs, and several others,
have IRS.
When you write a + b, JE passes a and b to the + verb. Even though its
rank is 0, + knows better than to chop up the arguments into atoms:
instead it processes them as vectors, repeating a short-frame argument
if needed. That's IRS for you: even though the verb has nominal rank 0,
it can use the SIMD instructions. The result is AS IF the processing
were at rank 0.
When you write a +"1 b or a +/ b, JE does even more for you. JE notes
that + supports IRS, so it avoids the explicit chopping-up step and
passes a and b to + . + now has more work to do: rather than just
repeating a short argument, it must also repeat over inner cells, with 4
nested loops. If you perversely write +"0, JE will set up the 4 loops,
then see that two are nugatory, and revert to just one or two loops.
What's the practical effect of all this? You provided a great example
by pointing out that it makes perfect sense to think of scalar and
vector addition as different operations. What the beginner needs to do
is note that the rank of + is 0, which means that if you want scalar
addition you don't need to write +"0: + means the same thing. The added
"0 might seem harmless, or even useful for documentation, but it does
add to the interpreter's work. If you are adding vectors, write +"1
only when it would give different results from +"0, that is, when you
have one vector to add to an array of vectors.
The apparent anomaly of sin is because of the details of the & and o.
primitives. o. has rank 0 with IRS, but m&o. is defined as having
infinite rank (with IRS). So yes, sin has infinite rank. But because
it's a monad, it produces the same results no matter what its rank:
there is no extension of a short argument.
Henry Rich
which knows to repeat an argument that
On 1/16/2021 8:59 PM, Arnab Chakraborty wrote:
Thanks for the lively discussion, much of which I could not follow, though,
owing to my ignorance about rank integration.
However, I understand that some sort of efficiency issue is involved.
BTW, I can answer one question that even Henry could not answer (for a
change): why beginners write things like +"0 and sin"0.
They (read "we") are confused by ranks, and the closest concept familiar to
them is that of dimension of domain. For instance, scalar addition is
different from vector addition. So +"0 is scalar addition, and +"1 is
vector addition. This habit is further encouraged by the apparently
inconsistent rank system of J, like *: having rank 0 while sin has rank
infinity. But both are functions from IR to IR. Not sure what is happening
internally, they prefer to explicitly "specify the domain."
Indeed, before this email thread, it never occurred to me that rank is
somehow linked with efficiency. I just considered a function's rank to be a
property that is competely dictated by the math of the function.
On Sun, 17 Jan 2021, 06:46 Henry Rich, <[email protected]> wrote:
I can't answer that, but I can assure you that they do.
Henry Rich
On 1/16/2021 7:38 PM, bill lam wrote:
I didn't mean to change stdlib sooner or later, but if we do it again,
rank
0 should be a better option.
Why users (beginner or not) would write a+"0 b or sin"0 ?
On Sun, Jan 17, 2021, 8:20 AM Henry Rich <[email protected]> wrote:
I would be happy for a user to do that, but changing stdlib might not be
a good idea. Beginning users often write
a +"0 b
and it doesn't cost them dearly. If you make the change, sin"0 will be
expensive.
Henry Rich
On 1/16/2021 7:17 PM, bill lam wrote:
Thanks. then defining sine as 1&o."0 should be fine.
On Sun, Jan 17, 2021, 8:07 AM Henry Rich <[email protected]> wrote:
What makes them efficient is IRS. 1&o. supports IRS; 1&o."0 does not.
Is you define sin as 1&o."0, sin will run fast, but sin"0 will not.
Henry Rich
On 1/16/2021 6:24 PM, bill lam wrote:
IIUC All atomic math functions are rank 0 but support IRS so that
they
are
as efficient as rank infinity on long array arguments.
The question should be that
is 1&o."0 as efficient as 1&o. on long arrays.
On Sun, Jan 17, 2021, 12:32 AM Henry Rich <[email protected]>
wrote:
Terminology. If verb v has IRS, it can handle v"n internally
without
a
rank loop.
+ has IRS. +"n does not need a rank loop.
+"n does not have IRS. +"n"n2 does need a rank loop.
+/@:*"1 has IRS, but +/@:* does not - that's how they're coded.
1&o."0 does not have IRS.
Henry Rich
On 1/16/2021 11:27 AM, bill lam wrote:
but the verb in this question is
(1&o.)"0
even if 1&o. has IRS, does (1&o.)"0 also has IRS ?
On Sun, Jan 17, 2021, 12:02 AM Henry Rich <[email protected]>
wrote:
m&v does have IRS if v does. I didn't know that until I just
checked.
Henry Rich
On 1/16/2021 7:10 AM, bill lam wrote:
I'm not sure if 1&o."0 has IRS (integrated rank support) or not.
If
it
doesn't then I think the phase with infinity rank is fine.
On Sat, Jan 16, 2021, 7:02 PM Arnab Chakraborty <
[email protected]>
wrote:
Dear all,
Just wondering if the correct defn of sin shouldn't be
sin=:1&o."0
instead of
sin=:1&o.
which has rank infinity.
With the rank infinity definition +/@sin behaves just like
+/@:sin
But, ideally, +/@sin 4 5 should be a list of two numbers, while
+/@:sin
should be their sum.
Just like, +/@*: and +/@:*:
Thanks and regards,
Arnab
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
