Very teasing Jacob 
You wouldnāt happen to have some laying around would you? Perhaps with one for circles? 
Do you have any thoughts on the behaviour of the count nodeā¦ is it bug worthy? Otherwise weāll be forced to use a python solution!
Hello Kenny,
Epic to see you playing with Python! Would love to have you contribute. The resource is by the community, for the community (And focused upon heavy annotation!).
In order to contribute, follow the steps outlined below:
- Sign up for a Github account (https://github.com/join?source=header-home)
- Navigate to the repo: https://github.com/Amoursol/dynamoPython
- Click on the Fork button on the upper right (This will make a personal copy of the entire repo for you under your login details)
- Locate the Create New File link next to Clone and Download
- Copy and Paste in your Python code direct from Dynamo and give it a Name at the top (Please refer to the ReadMe for naming conventions)
- Select the Create a New Branch option and fill in the name and details of your changes.
- Click on the Create Pull Request button. This will propose changes to the Master Github file which an admin of said repo will have to accept to merge into the Master.
If you have any issues simply ask away! Please read the ReadMe to adhere to submission criteria.
3 Likes
@Mark.Ackerley - I showed an example graph (a functional albeit very basic one), and discussed some of the methods we see customers using for space planning option generation in a Generative Design workflow today during the Generative Design for Busy People webinar today. Hope you made it. 
If not, donāt fret. The recording will be posted shortly.
As far as the list issue goes, I would say itās not a bug. By feeding the List @ level 1 youāre effectively feeding elements which donāt exist (null) to the node and the modification or inquarry function of almost anything applied to nothing will be nothing (some obvious things excepting). Try @L2 with longest lacing, or make a list of each level and flatten that to get single items or pairs of items at the same level.
Hi Jacob, where do you find out about webinars and things your up too?
The Generative Design for Busy People webinars are something worth following and are currently open to all, and can be watched/followed on the EP hub.
https://enterprisehub.autodesk.com/articles/generative-design-for-busy-people
Also, I will be at AU, where I will be on a panel about Revit Integrations (searching for me by name usually turns up the class but search appears to be down at the moment). I do hope to get to meet many users and community members while Iām there. If you see me, do say hello.
Thanks Jacob, I didnāt know about those
To take the gist of your point, of course we can argue that from a programming perspective it is correctā¦ But for me, that kind of misses the point, weāre not after a pure programming output, weāre after a useful predictable output, I wonāt use that node now, Iāll use the python solution, so no one winsā¦
To take the specifics of your point, could you explain again why the count behaves as it does?
It returns 9 by default, which is correct. But then if itās forced to level 1 it returns 3 (are which I would say is incorrect, is should be outputting 9?). Then it outputs 9 at level 2, which I would say is incorrect (it should output 3?). Is it flattening the list before counting?
EDIT: I was wrong about how levels were working, thanks a lot Kenny for the explanation
Thanks,
Mark
The best I can explain it from my understanding is that Count without levels specified is basically taking count at the largest level and then flattening it into a single integer output. Once you use levels, it stops flattening the final output.
When you use levels, it just counts how many elements are in that level. In your example, element 4 at @L2 is a list containing 3 elements, while everything else is just a single element. So when you use Count@L2, it is 1 for everything except for index 4, where it is a list of 3.
At Count@L1, only 3 elements are at that level in the entire list but each one is a single element, so counting it produces 3 counts of 1.
Edit: I think you might have the levels order mixed up.
1 Like
Haha sorry I reread it and realized I explained pretty poorly. Let me try to draw it out real quick.
I added another level deep and put what level each element is considered at in it. The main list is @L4.
Start with counting at @L3, using the above picture (letters instead of numbers). Each item at @L3 is considered a list of elements when counting at L3. A single element becomes a list of length 1, so when you count index 0 (āa@L3ā), it is 1. When you get to index 4, that list has length 3, so count is 3 (donāt count how many elements are total in the list, just the immediate list one level deeper. See below:
With @L2, first find how many elements are at L2. In this case, they are all inside @L3 index 4 (["e@L2", a list,"h@L2"]). Turn the elements into a list if they are not already and then count. [f@L1,"g@L1"] is already a list of length 2 so it is counted as 2. List structure is removed (unless checked).
I guess the confusing part is that you basically count one level deeper in a sense. But it corresponds to the actual level your count is set at.
2 Likes
Thanks for your efforts!
So the big question, is how useful and predictable is this behaviour?
As Kenny points out @L3 position 4, it shows me 3 itemsā¦ 2 doubles and a list. I donāt understand a situation where a variable wants to be summed, itās not a piece of curtain walling, itās a programming artifact. However Iām always happy to learn
To go all the way back, the inability to maintain list structure does seem quite a limitation to the usability of node. I personally will be using the python for these situations rather than 20 odd nodesā¦ Even to get Albanās solution working weāll need to add a back stop sub-list to stop those end nulls dropping off.
From a user perspective, I would prefer the node to Count 0 where there are 0 items, count all items, not lists, and not miss any off the end!
Apologies for the rambleā¦
Mark
1 Like
I donāt think it is the opposite of every other node. I am pretty sure every node follows this level order, as far as I can tell.
GetItemAtIndex has similar behavior:
1 Like
Thatās up to you if you want to delete or not. I am sure many other people have had the same misconception, as I did too for a long time. I finally had to bite the bullet and learn more about list levels after seeing a post by @mellouze. The primer doesnāt tell you enough.
1 Like
Haha, glad I helped somebody without even noticing Was that the post with the @@L2 notation ?
1 Like
Yeah haha 
I literally would never have figured this out. Thank you!
Hi Jacob! What do you mean single version outcomes? Like packing to one sheet. Not multiple?
Itās been awhile since I wrote that (4+ years), so I have no clue. You can almost certainly utilize the refinery toolkit for this now.
I shall investigate again but I think they didnāt have the right packing method I was after.
Which method were you after?
I think it was the next fit but place different size squares top left across and then down. Trying to the find document I looked at ages ago