Re: [Jprogramming] x u/. y Key

Looks promising. Typically, the strings are different lengths, and we may not have access to them at the same time. (Which is why I hade the intermediate summary step.) Let me ponder that (I don't think it will matter) while I study your approach more. Thanks very much! > On Oct 12, 2019, at 1:

Re: [Jprogramming] x u/. y Key

Here's one approach... I find it much easier to work with if there is actual data. The following may not be representative of your data but it gives us somewhere to start. ]'X Y'=: 'actg' {~ 2 30 ?@$ 4 ggttgactgtagtgaagaaggagtcc ctgattaaggttcggtgtcgataccgcgca We now have 2 strings X and

Re: [Jprogramming] x u/. y Key

Sure, thanks. I'm working to re-implement a text comparison program I did using VBA & Microsoft Access a number of years back. The object is to compare two text documents and see how similar one is to the other by comparing the number of unique trigrams that are found in each. For each text s

Re: [Jprogramming] x u/. y Key

Not sure I'm understanding your questions. Maybe including some of the expressions you've tried to illustrate your points would help? Basically the left argument to Key is used to categorise/group the right argument. Each unique item of the left argument tags a grouping of items in the right argum

[Jprogramming] x u/. y Key

I had high hopes for the functions of Key (particularly #/.~ M) for tallying the keys in a character matrix. Playing with it, and replacing verb # with others (< or { or ;) just to try to better understand its behavior, answered one question that I had: was this some serendipitous marriage of a

Re: [Jprogramming] Difference between complex literals and complex numbers produced by j.

Here's a link to a PDF of Eugene McDonnell's Complex Floor Paper I keep on my Google Drive: http://bit.ly/2Ma6nA9 Skip Cave Cave Consulting LLC On Fri, Oct 11, 2019 at 11:51 AM R.E. Boss wrote: > > Namens Marshall Lochbaum > > Verzonden: vrijdag 11 oktober 2019 17:07 >

Re: [Jprogramming] A Cheat Sheet!

> Namens Raul Miller > Verzonden: vrijdag 11 oktober 2019 18:22 (...) > (My favorite J cheat sheet is > https://www.jsoftware.com/help/dictionary/vocabul.htm but that one sort > of requires some familiarity with the language.) It was my favorite too, until it was no longer up to date. And I doubt

Re: [Jprogramming] Difference between complex literals and complex numbers produced by j.

> Namens Marshall Lochbaum > Verzonden: vrijdag 11 oktober 2019 17:07 (...) > J's implementation seems to be an attempt to follow the XAPL standard > (ISO/IEC 13751:2001), which is not freely available. The standard is > ambiguous, since it uses the undefined terms "fractional-parts" and > "nearer"

Re: [Jprogramming] A Cheat Sheet!

On Fri, Oct 11, 2019 at 12:19 PM Dan Kilman wrote: > The cheat sheet repo can be found here > . > > I'll be more than happy to accept PR's with improvements and whatnot. Hmm... I am not sure I can think of anything to contribute. (My favorite J cheat s

[Jprogramming] A Cheat Sheet!

I've recently finished reading Learning J and made a summary of it in the form of what turned out to be a cheat sheet. I did manage to find two similar sources (here

Re: [Jprogramming] Difference between complex literals and complex numbers produced by j.

Hi, you cab find it here, dating back to october 2017 : https://web.archive.org/web/20171003020856/http://www.jsoftware.com/papers/eem/complexfloor1.htm On Fri, Oct 11, 2019 at 11:07 AM Marshall Lochbaum wrote: > > > The page http://www.jsoftware.com/papers/eem/complexfloor1.htm, which > descr

Re: [Jprogramming] Difference between complex literals and complex numbers produced by j.

I think you have plenty of cause for confusion here. As far as I'm aware, there is no source which clearly and correctly documents the behaviour of J's tolerant complex floor. It's also a poor design in my opinion: in particular it fails to satisfy the desirable property that if c=z for a complex i

Re: [Jprogramming] Difference between complex literals and complex numbers produced by j.

And you run the risk of having the number being converted back to the "higher" type as soon as a computation is done on it. On Fri, Oct 11, 2019 at 7:28 AM Henry Rich wrote: > Converting numeric results to smallest valid type would be very > time-consuming. > > Henry Rich > > On 10/11/2019 6:51

Re: [Jprogramming] Difference between complex literals and complex numbers produced by j.

Converting numeric results to smallest valid type would be very time-consuming. Henry Rich On 10/11/2019 6:51 AM, ethiejiesa via Programming wrote: I assume this is well known by the cognoscenti, but I just ran into a newbie surprise: <. _1e_14j0 _1 <. _1e_14 j. 0 0

[Jprogramming] Difference between complex literals and complex numbers produced by j.

I assume this is well known by the cognoscenti, but I just ran into a newbie surprise: <. _1e_14j0 _1 <. _1e_14 j. 0 0 This came about as I was learning about and playing with the complex floor. Apparently, the differing behaviour traces back to how tolerance is handled