Yes, but to Devon's point, having a direct transliteration of an algorithm originally expressed in a (very) different language doesn't tell us anything about J's power (or not) to express that algorithm.
Any programming language worth discussing is Turing complete. Which means they're all *capable* of expressing anything computable (which means anything you, a human, could do with a sufficient supply of paper, pencils, and time). Each can express anything any of the others can express. So asking "can J express X?" isn't the interesting question (the answer is "yes"). The interesting question is: what does J make it *simple* to express? And, by implication (because several of the most fundamental theories humans have developed to date, and all of human experience prior to that, tell us that every decision is a tradeoff, and every benefit comes at a cost), what does it make harder to express? You will note that Thomas' excellent contribution achieves its practical results by implementing a stack language (that is, another programming language) inside of J. -Dan PS: It's worth pointing out that you yourself (Raul) have drawn the distinction between "doable, practically speaking" and "convenient" (or may I say, "elegant"?) in your proposed enhancements to FSM (dyad ;:): http://www.jsoftware.com/pipermail/chat/2014-January/005653.html And, for whatever it's worth, I agree with you: http://www.jsoftware.com/pipermail/general/2005-September/024446.html Please excuse typos; sent from a phone. > On Sep 8, 2014, at 6:37 PM, Raul Miller <rauldmil...@gmail.com> wrote: > > It is, nevertheless, an implementation. > > And anyone that feels like doing so can supply other alternates (or > replace it, if they feel theirs is good enough). > > Thanks, > > -- > Raul > > >> On Mon, Sep 8, 2014 at 5:28 PM, Devon McCormick <devon...@gmail.com> wrote: >> This looks like a transliteration from another language - not J-like at >> all. Once clue is that it's several times as long as many of the other >> implementations. >> >> >>> On Mon, Sep 8, 2014 at 4:05 PM, Joe Bogner <joebog...@gmail.com> wrote: >>> >>> I found an implementation of red-black trees on rosettacode: >>> http://rosettacode.org/wiki/Pattern_matching#J ... It might be relevant >>> or >>> may not be. >>> >>> On Mon, Sep 8, 2014 at 3:45 PM, Devon McCormick <devon...@gmail.com> >>> wrote: >>> >>>> A little research clarified what we see here: apparently it's part of the >>>> definition of a binary tree that the left node be smaller than its parent >>>> but the right one is greater. Right away, I see a problem for the >>>> predecessor-index representation of a tree that I'm advocating as it does >>>> not distinguish between right and left nodes as it is usually >>> implemented. >>>> >>>> >>>> On Mon, Sep 8, 2014 at 3:03 PM, Devon McCormick <devon...@gmail.com> >>>> wrote: >>>> >>>>> Do you have a reference to a good example of this? Looking at the >>>>> "before" and "after" pictures on the right here - >>>>> http://en.wikipedia.org/wiki/Self-balancing_binary_search_tree - the >>>>> rebalancing seems arbitrary as it preserves some relations but changes >>>>> others. >>>>> >>>>> >>>>>> On Mon, Sep 8, 2014 at 2:30 PM, Dan Bron <j...@bron.us> wrote: >>>>>> >>>>>> Raul wrote: >>>>>>> Note that J already supports trees. >>>>>> >>>>>> Devon wrote: >>>>>>> I have J code that uses trees which I run daily and >>>>>>> have been doing so for years. >>>>>> >>>>>> Pascal wrote: >>>>>>> I think trees are done at least ok, if not "right" already. >>>>>> >>>>>> Challenge: express, in J, the logic of rebalancing a heap (say, a >>>>>> Fibonacci >>>>>> heap, but I'm not particularly picky). >>>>>> >>>>>> For the sake of this exercise, you may ignore considerations of >>>> efficiency >>>>>> (though that's a bit of a self-contradiction, because heaps are >>>> frequently >>>>>> introduced specifically for the sake of efficiency). I am only >>>> interested >>>>>> in the directness, simplicity, elegance (lyricality) of the notation, >>> in >>>>>> its current form, for expressing ideas about trees. We can make it >>>>>> efficient "later" (Pepe's TCO utility is a start). >>>>>> >>>>>> -Dan >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> For information about J forums see >>> http://www.jsoftware.com/forums.htm >>>>> >>>>> >>>>> >>>>> -- >>>>> Devon McCormick, CFA >>>> >>>> >>>> -- >>>> Devon McCormick, CFA >>>> ---------------------------------------------------------------------- >>>> For information about J forums see http://www.jsoftware.com/forums.htm >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >> >> >> >> -- >> Devon McCormick, CFA >> ---------------------------------------------------------------------- >> 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
