Combine node null error

chaynes56's Avatar

chaynes56

20 Dec, 2020 04:41 PM

In the attached drawing, the quad curve is visible as the arc at far right, via combine1.

I'd like this curve to be copied along with the log spiral, so introduced combine3 and tried to move the spiral to its first input. But then get a null error. Could be another bug in my understanding, or possibly the system.

BTW, my first post about double clicking hasn't been an issue for some time, so that could be closed. My second and third posts indicate known and new bugs, respectively.

  1. Support Staff 1 Posted by john on 21 Dec, 2020 12:21 AM

    john's Avatar

    Hi Chris,

    Before I could figure out your network, I had to clean it up. See before and after image (attached).

    Aside: I have learned over the years how important it is to space out and align my nodes so that all the links are clearly visible and the overall top-to-bottom flow is readily apparent. I find it soothing to do this as I go - like flower arranging. But it's also deeply practical, especially when you come back to a network after a few weeks. A clean tree structure is much easier to scan than a hairball. This is the NodeBox equivalent to writing clean, well-formatted code in other languages.

    The file you attached did not have the error evident, but I assume you meant the null error that would occur if you fed quad_curve1 (near lower left) into combine3.

    If so, this is not a bug. It is a fundamental rule in Nodebox: no loops are allowed. Your network must be a tree with no cycles. You cannot feed the output of a node into any node directly or indirectly feeding into that node. (This is another reason for keeping your networks tidy: it makes such inadvertent cycles much easier to spot.)

    In this case, the point2 port of quad_curve1 is fed by a series of nodes tied to the output of combine3. If you try to feed the output of quad_curve1 back into one of the inputs of combine3 you would create a cycle.

    (I admit that the error "null" is not very helpful in describing the issue; NodeBox probably doesn't "know" there is a cycle, it only knows that something somewhere is not right.)

    The solution is to define your quad curve independently of your log spiral and THEN combine them - which appears to be what you did.

    Let me know if that makes sense. Looks like the thing you're making is pretty, by the way.

    John

  2. 2 Posted by chaynes56 on 21 Dec, 2020 02:11 PM

    chaynes56's Avatar

    Thanks a lot for the cleanup and invaluable advice.

    I’m a stickler for program formatting style, so readily appreciate your point. It takes time with an entirely new style of programming to appreciate what good style is, as most of it has to do with retaining program comprehension at larger scales. I had great difficulty impressing this on students who had no experience with large programs. Since Nodebox's visual network approach is entirely different from structured text, it has very different scaling problems. I have a large monitor, but eyes that are’t as good as they used to be, so I’ve been working to compress the structure to fit in limited area. I need to get comfortable with scrolling the network window, and when that’s too awkward, using subnetworks. I’d like to better understand the semantic effects of the latter.

    Problems with cyclic structures are, of course, one of the most important themes in C.S., so I readily appreciate this limitation in NB (which I might have been clever enough to anticipate). I can’t imagine it not being explicitly checked for, so a more helpful message shouldn’t be hard. At the least, it should be mentioned in the How NodeBox Works section of the documentation.

    In this network, the arc geometry needs to connect end-of-path points generated by the copy, and the arc itself needs to be copied in the same way (to complete the perimeter of the mandala). But it won’t be much harder to add another copy for that purpose, thus avoiding the circularity. NB would be much more powerful if it allowed circularities, such as I was trying to create, that converge after a few iterations. But that would slow it down and add to its conceptual and implementation complexity.

    Chris

  3. Support Staff 3 Posted by john on 30 Dec, 2020 03:42 AM

    john's Avatar

    Chris,

    I enjoyed your thoughtful comments and agree with all of them.

    It does take experience to appreciate good style and NodeBox does have very different scaling problems. Many people use NodeBox only to make quick sketches, but I regularly use it to make huge networks with thousands of nodes that can run twelve levels deep in subnetworks; at that scale visual styling becomes crucial.

    I also have eyes that aren't as good as they once were. At work I had a ginormous monitor that was a joy to use with NodeBox, but I have recently retired and currently do all my work on my laptop (which I'm used to). As a result I do spend much time scrolling and so try to strike a balance between compactness and clarity, but prefer to error on the side of clarity.

    You are right that subnetworks are the key to keeping things under control - both clear and compact. When you start playing with them you will learn that they are not merely for encapsulating content, though. Their primary power is in controlling the choreography of signal transmission by determining whether each port should be read in one value at a time (value) or all at once (list). This is a subtle point, well hidden in the UI, that caused me much confusion when I was first starting out. I have written about it extensively in the forums. If you have any trouble, please seek me out and I'll help you master it.

    NodeBox's rather severe limitations, no cycles, no state, no global variables, do create challenges, making some things which are easy to do in other languages harder to do in NodeBox. The silver lining, though, is that it greatly reduces the amount of debugging required. Even with very complex networks, bugs occur much less often in NodeBox and are much easier to track down. The really subtle killer bugs are not even possible. I became bone-tired of hunting for stray semicolons or mismatched braces in "normal" languages; once liberated from this I never looked back.

    The one limitation I chafe against and have long complained about is the inability for NodeBox to do recursion. This is a curious omission in a Lisp-like language, and could be remedied without breaking the paradigm. I have found a few workarounds and have created things like Conway's Game of Life in NodeBox by writing and reading an external file. You can also create subnetworks which can be chained together to an arbitrary depth, which is good enough in some situations. If worse comes to worse, you can also resort to custom nodes in Python or Clojure.

    I hope you will keep at it. You clearly have some deep insights into the potential power of NodeBox.

    John

  4. 4 Posted by chaynes56 on 03 Jan, 2021 04:22 PM

    chaynes56's Avatar

    Thanks for these thoughts. Your experience with huge NB programs is inspiring! Only experience will give me a working feel for it, but your few words on subnetworks is helpful.

    I readily appreciate the ease of debugging coming directly from the limitations of NB. In particular, experience with purely functional programming makes clear the advantages of the absence of state. Also the power of recursion, though my understanding of NB is still so limited I don’t understand just how that would be different from cycles; perhaps through reference to named subnetworks?

    There’s a place for purely functional languages, as well as those like python/clojure/scheme that enable it but don’t enforce it. And those like SQL that don’t support general iteration or recursion, thereby loosing Touring completeness, but gaining guaranteed termination (easier debugging!).

    It looks like NB development stalled some years ago, which seems a great pity. Not just NB3, but also NB1/2, which no longer work at all with the current MacOS. The visual style of NB3 is very powerful, but for some purposes a purely textual language has the greater power. Scaling problems have been largely solved in the latter context with modern OOP, library management, and IDEs.

    Chris

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Already uploaded files

  • mandala2.ndbx.zip 1.78 KB

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

17 Jan, 2021 04:53 AM
16 Jan, 2021 04:26 PM
15 Jan, 2021 03:28 PM
15 Jan, 2021 03:22 PM
15 Jan, 2021 09:46 AM

 

13 Jan, 2021 03:56 AM
05 Jan, 2021 07:23 AM
05 Jan, 2021 06:37 AM
04 Jan, 2021 10:42 PM
03 Jan, 2021 04:22 PM
30 Dec, 2020 02:52 AM