Again:
([: u v) is equivalent to u@:v NOT u@v .
([: u v y) is a domain error.
Henry Rich
On 1/21/2016 4:54 AM, Linda A Alvord wrote:
I wasn't considering all special code!
([: u v y) and (u@v y) are supposed to be equivalent.
f=: 13 :'u v y'
f
[: u v
g=: 13 :'u@v y'
g
u@v
As Mike suggested "Is there a danger, if g always uses special code, in using that
same code for f?"
Linda
-----Original Message-----
From: Programming [mailto:[email protected]] On Behalf
Of Raul Miller
Sent: Thursday, January 21, 2016 2:18 AM
To: Programming forum
Subject: Re: [Jprogramming] A Different Less?
Merging independently evolved code generally requires some care, thought,
effort and testing (especially corner cases). One of the risks, for example, is
that errors in one implementation will be propagated to the other, leaving
people without any workaround.
Another is lurking "moving parts".
Those error modes are probably not an issue here, but it's something to keep in
mind.
FYI,
--
Raul
On Wed, Jan 20, 2016 at 11:27 PM, Marshall Lochbaum
<[email protected]> wrote:
Short answer: as far as I can tell, this is never the case.
Special code identification for forks is handled in the function jtfolk
in cf.c, with the case of capped forks (but also some other cases!)
handled in the block that begins "switch(fi==CCAP?gi:hi){". Special code
for at (@:) and atop (@) constructs is identified in jtatop and jtatco,
in ca.c. These are quite difficult to read (and require constant
character lookups from jc.h), but I have figured out what all the capped
forks do and each of those is also handled in jtatco (@:). So unless
there is other special code hiding out someplace or I made a mistake,
the situation you describe can't happen.
It's somewhat confusing that special code for (@:) is handled
differently from that for forks. I can't see any problems with using the
same verb for both, and it's not difficult to implement. A small amount
of code is shared between regular and capped forks, but it is far less
than would be eliminated by merging capped forks and (@:) statements.
There's also no performance hit in the case of non-capped forks.
Marshall
On Wed, Jan 20, 2016 at 06:09:11PM -0500, Jose Mario Quintana wrote:
The experiment was for the specific performance of [: u v vs u @: v for the
given u, v, X and Y. However, there are other instances as well, for
example, the reference [2]. I do not recall seen any instance of such
discrepancy in performance the other way around; that is when [: u v
clearly dominates u @: v but I would be grateful if you or anyone else
points me in that direction.
On Wed, Jan 20, 2016 at 5:40 PM, Henry Rich <[email protected]> wrote:
The experiment you made is insufficient for the purpose.
Usually when u@:v is fast, ([: u v) gets the same treatment. Since
/:@:/: is fast, I expected ([: /: /:) to be also. (It's not, surprisingly).
/:@:/: is handled same as /:@/: since they are equivalent.
<.@% is fast, but there is no reason to expect ([: <. %~) to be fast, for
two reasons:
1. They have different rank. But <.@:% is also fast, so it turns out
this is not the difference.
2. Since <.@:% is fast, so will <.@:%~ be, and normally ([: <. %) too;
but ([: <. %~) is totally different. It is equivalent to <.@:(%~) which
is NOT fast.
I have not been able to figure out what the verbs f are for which <.@f is
fast.
Henry Rich
On 1/20/2016 8:31 AM, 'Pascal Jasmin' via Programming wrote:
does [:/:/: not also benefit from special code?
I doubt it does,
timespacex '123 ([: <. %~) 210293810238120398120398120398x + i.1000'
0.00241248 1.27885e6
timespacex '123 ( <.@%~) 210293810238120398120398120398x + i.1000'
0.000590399 836992
----- Original Message -----
From: Mike Day <[email protected]>
To: [email protected]
Sent: Wednesday, January 20, 2016 7:50 AM
Subject: Re: [Jprogramming] A Different Less?
I wasn't advocating /:/: . I prefer using @ but the 13 : ' .... '
had produced [:/:/: . Conicidentally, Linda appears to
favour the [:u v idiom to u@v .
So, for Linda's benefit, does [:/:/: not also benefit from
special code?
Mike
On 20/01/2016 12:29, Henry Rich wrote:
Note: /:@/: y is better than /: /: y (special code)
Henry Rich
On 1/20/2016 5:45 AM, Mike Day wrote:
Maybe simpler but it requires evaluation of /:/:y twice, whereas
Raul's oc manages to make rank the right hand argument to (] - {) .
This tacitisation might be what you're looking for:
13 :'r-(i.~ y){ r =./:/:y'
i.~ (] - {) [: /: /:
It reproduces oc except for using [: rather than @ !
Mike
On 20/01/2016 10:27, Linda A Alvord wrote:
A simpler f:
f=: 13 :'(/:/:y)-(i.~ y){/:/:y'
f
([: /: /:) - i.~ { [: /: /:
Linda
-----Original Message-----
From: Programming [mailto:[email protected]]
On Behalf Of Linda A Alvord
Sent: Wednesday, January 20, 2016 3:15 AM
To: [email protected]
Subject: Re: [Jprogramming] A Different Less?
Here's another way to write the code that so far is the fastest. How
does it compare?
A=:'abcabbe'
B=:'babe'
f=: 13 :'(/:/:y)-(y i. y){/:/:y'
g=: 13 :'((f x)>: (( ~.y)i.x){(#/.~y),0: y)#x'
A g B
cab
f
([: /: /:) - i.~ { [: /: /:
g
[ #~ ([: f [) >: ([ i.~ [: ~. ]) { ([: #/.~ ]) , [: 0: ]
Linda
-----Original Message-----
From: Programming [mailto:[email protected]]
On Behalf Of Raul Miller
Sent: Monday, January 18, 2016 12:51 PM
To: Programming forum
Subject: Re: [Jprogramming] A Different Less?
Hmm...
A bugfixed version of my previous implementation (it broke when x -.
y was empty) performs approximately the same, for me:
cle=: ,~ #~ i.@#@,~ e. [: ; (2*#/.~@]) (}.&.>~ #@[ {. ])~ (]i.,~)
</. i.@#@,~
I say approximately, because timing variations mean that when I test
on the same data, sometimes it's faster and sometimes it's slower than
oc=: i.~ (] - {) /:@/:
cless =: [ #~ oc@:[ >: (i.~~.) { (#/.~,0:)@]
That said, Boss's implementation is clearly more concise...
Thanks,
--
Raul
On Mon, Jan 18, 2016 at 12:17 PM, Marshall Lochbaum
<[email protected]> wrote:
That's a very cool solution, and much quicker than the one based on
progressive index-of. Instead of taking the occurrence count of both x
and y, it just takes the count for x and compares it to the total
number of occurrences in y, given by (#/.~).
Here's a comparison of the two methods. It turns out in the version
based on progressive index-of, the desired verb can be obtained just
from replacing (i.) with (-.) and then using the first column of the
result to select from x, so I've used that version.
NB. Shared verb for occurrence count
oc=: i.~ (] - {) /:@/:
NB. Simplified form of what Roger and I posted
cless1 =: [ {~ [: {."1 #@[ ({. -.&(,.oc) }.) [ i. ,
NB. Tacitized R.E. Boss solution
cless2 =: [ #~ oc@:[ >: (i.~~.) { (#/.~,0:)@]
NB. test data
'a b' =. 500 ({.;~}.) +&(1e5 ?@$ 26)&.(a.&i.) 'a'
10 (6!:2) 'a cless1 b'
0.0178952
10 (6!:2) 'a cless2 b'
0.0063745
a (cless1 -: cless2) b
1
To summarize, here's the fastest solution so far:
oc=: i.~ (] - {) /:@/:
cless =: [ #~ oc@:[ >: (i.~~.) { (#/.~,0:)@]
Marshall
On Mon, Jan 18, 2016 at 03:49:46PM +0000, R.E. Boss wrote:
I'm getting old, but still remember my solution, improved by Hui:
http://www.jsoftware.com/pipermail/general/2004-May/017503.html
'abcabbe' strikeb2 'babe'
cab
Curious how it performs compared to the other solutions.
R.E. Boss
-----Original Message-----
From: Programming [mailto:[email protected]]
On Behalf Of June Kim (???)
Sent: maandag 18 januari 2016 5:19
To: Programming forum <[email protected]>
Subject: [Jprogramming] A Different Less?
Hello
I am looking for a verb(cless) that does something similar to
Less(-.) but counting the elimination, for example:
'abcabbe' -. 'abbe'
c
'abcabbe' cless 'babe' NB. get rid of y letters counting the
occurrences
'cab'
It is easier to define such a verb recursively: 'abcabbe' cless
'babe'
equald to 'e' cless~ 'b' cless~ 'a' cless~ 'b' cless~ 'abcabbe'
I think recursive definition isn't a usual J-ic approach.
How would you implement such a verb elegantly(with which I mean
short)?
June
-------------------------------------------------------------------
--- 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 Avast antivirus software.
https://www.avast.com/antivirus
----------------------------------------------------------------------
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 Avast antivirus software.
https://www.avast.com/antivirus
----------------------------------------------------------------------
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
