Counting backward, why?


How can i change that it should get increment forward not backwart…?


flip the formula and use reverse

List.Reverse(x .. 9000)

or you can use -1

9000 .. x .. -1;

1 Like



i count generic-model-instances

i may understand you wrong, what is the desired list should be ? for example ?

that the count of the elements start by 9501 and ends with (9500+619=10.119)
the later issue is numbering openings!

The range syntax is from…to so you could just do this:

1 Like

so it is started with 9500 and increased by 619 , 9500…10119 … 10738 …etc. but is should end at what number ? i mean what is the last value ?

1 Like

cc @Michael_Kirschner2

This is a bit of contradiction:

? Logically, if I start at 10 and end at 1 and want to increment in steps of 1 this should work. And -1 would cause the exception?

1 Like

got It! thank you!


1 Like

I read the error state as ‘start at 10 and keep adding one until you get to 1’ which doesn’t ever get to the goal as you’re moving the wrong direction, while the working state I read as ‘start at 10 and keep adding negative one until you get to 1’, which actually happens as I am moving the right direction.

Can you elaborate a bit more as I may just be thinking of the syntax in the context of my experience which is very design script heavy.

1 Like

I understood it the same way as @Jacob. It seems like the range determines the direction of the sequence. By default, the step will have a magnitude of one but still match the direction of the sequence. If you provide a step that doesn’t match that direction then the node errors.

If I had to argue I’d say that increments have magnitude only, while steps also have direction. This makes an important distinction between the two when it comes to DS syntax and this issue.

Well there’s two aspects to consider:

  1. What Dynamo automatically does with the range syntax
  2. The semantics of the range syntax

1…10 semantically is “from 1 to 10 step by 1.”
10…1 semantically is “from 10 to 1 step by 1.”

Dynamo already knows the sign of the step because that how it is designed to work, so why would it allow negatives for the step size when it knows implicitly from the declaration of the ‘from’ and ‘to’ which sign to apply to the incrementor. My point being, why not throw the exception if a negative is input rather than a positive given that the sign is already known?

It just seems like a double negative and that’s the contradiction:
10…1 semantically is “from 10 to 1 step by -1.” Why allow negatives if the from and to already determines this? It’s just seems a bit pointless.

1 Like

hi Andreas
This will be generic try this out

1 Like