Talk:Essays/Tree Display

From J Wiki
Jump to navigation Jump to search

Suggestions for changes to this function

I recently discussed this page on the APL Farm j channel.

The gist of the discussion is that it would be nice if this representation distinguished a node's label from its identity. I posted the following diff to the code there:

diff -u trees{-save,}.ijs
--- trees-save.ijs    2024-07-14 11:44:33
+++ trees.ijs    2024-07-14 11:49:24
@@ -2,12 +2,8 @@
 EW  =: {: BOXC    NB. east-west
 
 tree=: 3 : 0
- assert. ($y) -: (#y),2
- y=. ":&.>^:(32 ~: 3!:0) y
- assert. ((2 = 3!:0&>) *. 1 >: #@$&>) y
- j=.  ~. , y
+ 'c j'=.y 
  t=. (<EW,' ') ,@<@,:@,&.> j           NB. GTs (generational trees)
- c=. |: j i. y
  while. +./ b=. ({.c)*.//.-.e.~/c do.
   i=. b#~.{.c                          NB. parents whose children are leaves
   j=. </./(({.c)e.i)#"1 c              NB. leaves grouped by parents

The issue is that this is a change to the API. Would it be better to

  • edit the code directly
  • Add an addendum with the changes to the code
  • Make a separate page possibly with cross-references between them

?

The difference in the API is that instead of taking a list of edges it would take a pair of a transposed list of edges and a list of labels per node. I'm happy to entertain other suggestions as well.

P.S. I don't do a lot of wiki. If there are some standards I should be following for this discussion, please let me know. Doug Mennella (talk) 05:38, 17 July 2024 (UTC)


I think that this is the correct way to go about your suggestion Doug, but I am not sure how much traffic will notice this talk page. If there has been no other interaction in a day or two you may want to post your question on the J forums and give a link to this page to drive some discussion. https://code.jsoftware.com/wiki/System/Forum

Also, I think that I will add the topic of talk pages to this week's wiki meeting agenda to try for a consensus on their use. Bob Therriault (talk) 06:11, 17 July 2024 (UTC)


My vote would favor "Add an addendum with the changes to the code" to make it easy to think about the revision process - with a brief description of parent trees and a couple small examples to illustrate the api.

I think the API issue is important (and would require other changes to the page - especially examples (and I should note that when I try the code with your diff I can't get it to work without error (so I may have misunderstood the scope of your changes, which would maybe mean that a different approach should be used))), and probably best addressed by supporting both tree representations, with two entry points. I'm not sure what the the name of the second entry point should be. It might be worth refactoring the code so that that most of the common lines are shared regardless of which api is used. It's probably also worth adding asserts for the parent tree representation. (Indices should be valid).

Also, thinking about this, the parent tree node labels should be optional (and by default should match index values), which suggests an ambivalent dyadic entry point for the parent tree variant). --Raul Miller (talk) 13:46, 17 July 2024 (UTC)


Is there a place to workshop a diff or is it all done directly in the edits? Also, I was mostly concerned about accurately reflecting the history of the code rather than having it be backwards compatible. In that vein I’m not sure refactoring is the right way to go. Also, it’s not like this is a library that will break existing code relying on it if it changed.

Doug Mennella (talk) 05:04, 20 July 2024 (UTC)


On the View History tab (top of the page, towards the righthand side), you can generate diffs between any two versions of the page. Internally, I believe the database also saves each past revision as a diff constructed against the next most recent version. But the UI presented to users and editors is just an editing interface - if you want to work with diffs in that context, the procedure would be:
  1. copy and paste content out of the editing window
  2. generate or whatever else your diffs and patches, and then when you're ready
  3. copy and paste the version of the page you you wish to have published back into the editing window, then [preview and] save the changes. (There's also a "Show Changes" option down there, of course, if you want to see your proposal in diff form.)
And, of course, if problems arise, other editors can revert your changes (which actually introduces a new instance of the page which is identical to some previous version - your change remains in the page history, baring catastrophic machine failure, or similarly unusual administrative intervention). --Raul Miller (talk) 07:08, 20 July 2024 (UTC)

Sorry. I think I’ve made not made myself plain. If I have an edit to the page that I’m not 100% fond of, should I simply make the change so other people can comment on it? Or is there some place to post ::the change where it can be workshopped before it’s official. I believe Wikipedia has a setup like the latter option. Doug Mennella (talk) 08:30, 20 July ::2024 (UTC)

Usual practice is to make the change. The older versions of the page still exist. If that becomes problematic, you could make a personal copy of the page and make the changes there, but we don't have the volume of upset people that wikipedia has, so review copies usually shouldn't be necessary. (And might draw out the revision process for that page for years.)
If there's a general direction or issue you where you want cooperation or advice from other editors but where the details might be irrelevant to users of the page, you could leave html comments within the page, leave notes (like this) on the talk page, leave a link to some secondary page, etc.
That said, where we have content from past luminaries (Ken Iverson especially, but Roger Hui and Eugene McDonnell also), I prefer to leave their presentation as intact as possible. --Raul Miller (talk) 19:36, 20 July 2024 (UTC)

Yes, this is precisely the history of the code I was referring to. All told, I'm kind of reluctant to make any changes now. FWIW, this is how you invoke the patched version of the code, though I suppose making it a dyad would have made more sense. This is what I was describing as a pair of the list of edges transposed and the labels.
   p=.0 0 1 0 3 3 0
   nodes=.}.@(,"0 i.&#)p
   lbls=.;":"0@i.#p
   tree ((|:nodes);lbls)
┌───────────────┐
│     ┌─ 1 ─── 2│
│     │     ┌─ 4│
│─ 0 ─┼─ 3 ─┴─ 5│
│     └─ 6      │
└───────────────┘

Doug Mennella (talk) 02:58, 21 July 2024 (UTC)

Ok, let me think about this. Maybe I'll make an addendum (or a introduce a secondary page). --Raul Miller (talk) 04:22, 21 July 2024 (UTC)