Hi all!
OK. Yes. Considering this the differences seem very small. Long ago I
remember looping programs I made 270 times faster by removing the loop
and using some recursive tricks. Now the looping solution can often even
be faster.
No one want's to answer the question if explicit code can replace tacit
code everywhere? $: did not seem to work in explicit code, but there is
also no need for it there.
I recognized you can even use explicit code in tacit. That's mean.
Global variables and all. Mutable state.
a=: 0.01
(+/ (4 :'x % y+a') #) 1 2 3
1.99336
Cheers,
Erling
On 2017-09-30 19:20, Henry Rich wrote:
Bill hit the nail on the head:
> IMO it doesn't matter whether to use tacit or explicit,
> the more important thing is to understand how J works.
u@:v y means 'Do v on y; then do u on that result'. It is exactly
the same as
(u v y).
u@v y means 'Do v on the first cell of y; then do v on that; repeat
for all cells'
If there are many cells in y, you will be repeating the overhead of
starting v and then u.
What is that overhead? In your examples using @, (1) parsing and (2)
bookkeeping.
Parsing: (3 :'-y')@- v is slow partly because every sentence of an
explicit entity is parsed anew when the sentence is executed. Thus the
sentence '- y' is parsed repeatedly. In
-@- y the verb, -@-, is parsed once.
Bookkeeping: every J noun can be an array with any type. Every time
you start a verb, each argument must be analyzed.
(3 :'-y')@- v starts 3 verbs for each cell: -, (3 :'-y'), and -
again. The - starts are quick, because they follow an optimized path
for arithmetic on singletons. (3 :'-y') is another story: starting an
explicit definition means getting ready for control structures,
creating a namespace, initializing the names xymnuv, and a bit more.
That's where most of the time is being spent.
-@- starts just the 2 verbs - and -, each of which is fast.
There are other overheads to the explicit form: (1) executing -y
requires looking up the name y (2) assigning the result of - to the
name y means that -y cannot be executed in-place, which is slower.
Finally, there is an overhead for splitting v into cells and
assembling the cell-results into a single array. This is small.
When you write u@:v, you have only 3 verbs to start: (u@:v), v, and
u. If u is explicit, you have the extra explicit overhead just once.
If you ran a test using @: on long v, I would expect the tacit code to
take less memory and time mostly because -@:- executes the first -
in-place while
3 : '-y'@:- doesn't.
Henry Rich
On 9/30/2017 10:24 AM, Erling Hellenäs wrote:
Hi all!
Yes, well, I wanted to measure differences between tacit and
explicit expressions as such, so I tried to avoid unrelated
processing time. In case you have significant operations, these
differences disappear, of course, and the processing time in these
operations dominate over interpretation time or small differences in
the code generated.
It seems better to create an internal loop then to have ts loop a big
number of times over a very small load, since the measurement process
as such might dominate in the latter case.
The way you measure, you have to set v low and n high to avoid
processing time, and it seems you didn't.
I understand that these differences might not be important in
practice. Thanks for your judgement on that.
Any other opinions about performance differences between tacit and
explicit code? Are there any cases when they are big?
ts=: 6!:2 , 7!:2@] NB. Time and space
v=.1
n=.5000000
n ts'(3 :''-y'')@:- v'
3.03253e_6 6784
n ts'(-)@:- v'
4.83682e_7 1152
v=.?~n
ts'(3 :''-y'')@- v'
1.8912 1.34712e9
ts'(-)@- v'
0.93178 1.34711e9
Cheers,
Erling
On 2017-09-30 13:13, bill lam wrote:
Since the time taking is small, better to run n times
to obtain an average.
+ and - are scalar functions of rank-0, but J has
integrated rank support so that there will be no
performance penalty if its arguments are arrays.
@ will inherent the rank of - , better to use @: in
this case.
50 ts'(3 :''-y'')@- v'
0.183617 8.39565e6
50 ts't@- v'
0.105698 8.3904e6
50 ts'(3 :''-y'')@:- v'
0.00245378 1.67837e7
50 ts't@:- v'
0.00206336 8.39002e6
IMO it doesn't matter whether to use tacit or explicit,
the more important thing is to understand how J works.
Сб, 30 сен 2017, Erling Hellenäs написал(а):
Hi all !
Can tacit and explicit J be interchangeably used everywhere ?
Examples of use:
4 (3 :'- y')@:(4 :'x + y') 5
_9
3(4 :'(1: x + y)#''x'' ')`(4 :'(1: x + y)#''y'' ')@.(4 :'x < y')4
y
What are the performance implications of using explicit J instead
of tacit
J?
This little example indicates that tacit J is about twice as fast?
v=.?~1000000
10{.v
733026 963097 739111 754321 510732 704647 209066 833891 281909 851842
#v
1000000
t=: -
e=: 3 :'-y'
ts't@- v'
0.49503 2.6439e8
ts'e@- v'
0.743922 2.6439e8
ts'(3 :''-y'')@- v'
0.38011 2.64395e8
ts'(-)@- v'
0.186993 2.6439e8
ts'-@- v'
0.182542 2.6439e8
ts'(3 :''- <: >: y'')@- v'
0.465578 2.64395e8
ts'([: - [: <: [: >: ])@- v'
0.25002 2.64391e8
*./ (t@- v) = v
1
*./ (e@- v) = v
1
*./ ((3 :'-y')@- v) = v
1
*./ ((-)@- v) = v
1
*./ (-@- v) = v
1
*./ ((3 :'- <: >: y')@- v) = v
1
*./ (([: - [: <: [: >: ])@- v) = v
1
Cheers,
Erling
On 2017-09-29 20:10, Erling Hellenäs wrote:
An additional comment. see below. /Erling
On 2017-09-29 04:45, Henry Rich wrote:
Taking your last sentence first, you would have to supply some
evidence to make me believe that tacit forms have any intrinsic
performance penalty.
It is dawning on me that you want fast function definition, but that
you want it to produce tacit code. You find the current tacit
language difficult, and you propose to replace it with something
that looks more like the explicit language. That seems like a
mistake to me, because:
1. Most of the responders on this Forum don't agree with you that
the tacit language is opaque
2. Even with a fast function definition, many J programmers (I dare
not say all J programmers with a soul) will always prefer (+ i.) to
(. x + i. y).
This is a strange comparison, (+ i.) is comparable to + i. with
explicit
syntax. [ ( + i. ) ] is comparable to x + i. y and ([ (+ i.) ]) is
comparable to (. x + i. y).
3. Tacit code is a different mindset from explicit code. It's
functional. It doesn't have assignments or control words
4. Operands to modifiers cannot be arguments to tacit code
5. Explicit syntax is an improvement in some cases, not all. +/ *:
y is a little lighter than +/@:* y but (+/ y) % #y is heavier than
(+/ % #) y
6. So: even if I were redesigning the language from scratch, I
wouldn't represent tacit forms your way. I would, as Roger has
observed, switch the meanings of (u v) and (u@:v), but I would keep
the rest as is.
[Note for those who have not been using J for more than 10 years:
the original tacit language allowed trains that produced modifiers.
That was, to me, Ken's finest achievement: a really beautiful
language, immensely supple, even though it had no syntactic elements
but the primitives and parentheses. I never found it wanting. It
was fully understood by no more than half a dozen people, I think.
It was removed from J because explicit forms could produce the same
results: a good business decision, but a loss to computer science
and art.]
7. The bottom line: tacit forms work pretty well as they are, and an
incompatible change to them could be justified only by a huge
improvement in readability or efficiency. You haven't shown that.
Henry Rich
On 9/28/2017 10:09 PM, Erling Hellenäs wrote:
Hi all !
Is improving explicit J the way forward? Or is tacit J and
improving tacit J the way forward?
I also think that "Henry's" proposal, which is similar to what I
have been writing about for a long time, is great. It is easy
to do and have great benefits for people working in explicit J.
They will not have to type lots of double quotes, or write their
own J versions with special duplicate quote functionality.
That doesn't mean that tacit J could not also be improved?
Henry's proposal is nearly identical to my proposal but mine is
about tacit J, it is addressing problems with tacit J. His is
about explicit J. It is addressing problems with explicit J, the
quote duplication problem. I am addressing problems with tacit
J, mainly the problem which makes people write cross-compilers
from explicit to tacit J or programs to automatically pack verb
sequences in tacit J into their packages of brackets and phony
"compositors", like this - f@:(g@:(h@:(i@:(j@:])))). People who
are working professionally with tacit J and who knows that
cheating and writing tacit J like most other people do will slow
their programs much too much?
Cheers,
Erling
On 2017-09-29 03:13, Joe Bogner wrote:
I also like Henry's suggestion of fast function definition.
It's also
unclear to me on how the Erling's suggestion improves upon that.
On Thu, Sep 28, 2017 at 5:45 PM, Louis de Forcrand
<[email protected]> wrote:
I don't really understand what you wish to add either, Erling.
If you want to use explicit J syntax, you could write an
explicit verb.
You write:
Particularly to create what you most commonly need, a
sequence of
monadic verbs, each acting on the result of the verb to the
right.
Well, it is not complicated as such, but for some
reason people don't
like
the obvious way to do it, which is [: f [: g [: h ].
Then they dive into
a
mess of complications. I mean the cap should not be
necessary. That
simple
right to left execution should be the default,
possibly modified with
parenthesis. That tacit and explicit J should have
the same basic syntax.
f@:g@:h?
In addition, I disagree with your last two sentences.
What's the point of
having tacit syntax if it's the same as explicit syntax? If
you want
explicit syntax, write an explicit verb; other times
tacit syntax is really
practical.
In an explicit verb, simple right to left execution *is* the
default.
In any case I don't really see how the rest of your
suggestion differs
from Henry's (.). verbs, which I like very much by the way.
Cheers,
Louis
On 28 Sep 2017, at 14:53, Raul Miller <[email protected]>
wrote:
Jose's work is impressive, but I try to avoid it
because of the extra
complexity it creates when I want to (for example)
provide a parameter
in clauses for conjunctions like &. -- the extra complexity
can be a
nice mental exercise and maybe even a cure for boredom, but I
feel
that I have the right to treat it as unnecessary.
Thanks,
--
Raul
On Thu, Sep 28, 2017 at 8:33 AM, Erling Hellenäs
<[email protected]> wrote:
Hi all !
I am very impressed by Jose's work and I think it is an
excellent
illustration to why we need the modification to J I propose.
It is extremely complicated to do these things
which should be simple,
as I
see it. Particularly to create what you most
commonly need, a sequence
of
monadic verbs, each acting on the result of the verb to the
right.
Well, it is not complicated as such, but for
some reason people don't
like
the obvious way to do it, which is [: f [: g [: h ]. Then
they dive
into a
mess of complications. I mean the cap should not be
necessary. That
simple
right to left execution should be the default,
possibly modified with
parenthesis. That tacit and explicit J should have the same
basic
syntax. I
tried my ideas of a different tacit J in a test
implementation and it
was
great.
Cheers,
Erling Hellenäs
On 2017-09-28 05:29, Jose Mario Quintana wrote:
Hi Erling,
You are right, the adverb (At) produces tacit sentences but
it is
really
an
implementation of Dan's pipeline proposal
using strand notation via a
Curried adverb (aka, recurrent adverb and multiple adverb).
However, I have written (tacitly) a tacit
Curried adverb (xi) which,
using
a lambda-style syntax, produces a tacit verb
which in turn, given its
arguments, produces tacit entities. You
might find xi interesting; the
general form is,
t=. [: v0 v1 ... vn '...' xi
The names v0 v1 ... vn should be
syntactically verbs (recall, xi is a
Curried adverb) but they can represent nouns, verbs,
adverbs, or
conjunctions. I use undefined names since those are
regarded by
default
as
verbs (even if xi does not affect in any way
the named verbs). The
literal
'...' represents a quoted J (or more generally a Jx) sentence.
This is how your example can be written using xi,
erase 'b v'
[: v '([: b ''<:b++/\b-~-.b'' xi
<''\''=v){."0 v' xi <'\\\//\\\//'
\
\
\
/
/
\
\
\
/
/
There is the nuisance of quotes within
quotes and the argument must be
boxed; however, this allows, in general, the verb (t) to
produce a
noun, a
verb, an adverb, or a conjunction and to
take multiple boxed nouns,
verbs,
adverbs, or conjunctions as its argument.
The following verb (t) acts
directly on a couple of (boxed) verbs and produces a verb,
t=. [: u v 'u/@:v' xi
t[:+*:]: NB. Sum of squares
+/@:*:
t[:+*:]: 1 2 3 4 5
55
t[:-%:]: NB. Difference of square roots
-/@:%:
t[:-%:]: 1 2 3 4 5
1.55390522
Note that the Curried higher-order verb (t)
is, in effect, acting on
two
arguments: [:-%:]: and 1 2 3 4 5;
furthermore, t [:-%:]: performs a
partial
application of the verb (t) acting on [:-%:]: .
The following are variations of the verb
produced in [0], the verb (t)
acts on a (boxed) conjunction and produces an adverb,
t=. [: u '(ver adv u)&:train/adv' xi
]`{.`{:`{: (t [:(<adv@:)]:) NB. Use [:(<'@:')sb in J
]@:({.@:({:@:{:))
]`{.`{:`{: (t [:(<adv@ )]:) NB. Use [:(<'@ ')sb in J
]@({.@({:@{:))
]`{.`{:`{: (t [:(<adv&:)]:) NB. Use [:(<'&:')sb in J
]&:({.&:({:&:{:))
These non-compliant features are not
provided by the Jx interpreter;
they
are, in fact, inherited from the J
interpreter, the Jx facilities just
make
them a lot more accessible. Actually, I have written a
version
(admittedly
cumbersome) of xi in J; see [1] for a link
to a zip archive and the
path
to
a script where xi is defined.
PS.
erase'u0 u1 u2'
1 1 1
[: u0 u1 u2 'u0 + u1 + u2' xi 1 ; 2 ; 3
6
erase'α β γ'
1 1 1
[: u0 u1 u2 'u0 + u1 + u2' xi [:α β γ]:
α + β + γ
References
[0] [Jprogramming] Gerund composed application
http://www.jsoftware.com/pipermail/programming/2017-
September/048797.html
[1] J Wicked Toolkit
http://www.2bestsystems.com/foundation/j/Jx.zip
\Jx\J\J Wicked Toolkit.ijs
On Wed, Sep 27, 2017 at 5:10 AM, Erling Hellenäs
<[email protected]>
wrote:
Hi all !
Pascal, I will come back to your post later.
Here is a little compiler written in Jx
and compiling, as I understand
it,
tacit code with explicit J syntax into
tacit J. I did not test it, I
just
read the post.
http://www.jsoftware.com/pipermail/programming/2017-
August/048143.html
The code snippet Farey is an example of
the source code of the little
compiler.
I just think we should not have to use a tacit J compiler
from
explicit J
to be able to use explicit J syntax and
get a tacit result, a single
verb.
It would obviously be better to use
explicit J syntax in the first
place,
as i see it.
Cheers,
Erling
------------------------------------------------------------
----------
For information about J forums see http://www.jsoftware.com/
forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
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.
http://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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
