This must be a bug because its true for dividing by all odd numbers:
(i-1)/3
(i-2)/5
(i-3)/7
(i-4)/9
(i-5)/11
....
(i-n)/2n+1
And you can't make it work for even numbers
Added by Danny Boyes at 5:06pm on January 13, 2010
I'm trying to retrieve data from a tag heuer timing system through rs 232. Firefly ports available says com ports 1 and 3 are available. Is one of those two the rs 232 9 pin? Thanks for your help.
What are B and C supposed to be? I mean, they have to resolve to actual numbers.
So given the tree:
{0} [0;1;2;3]
{1} [0;1;2;3]
{2} [0;1;2;3]
{3} [0;1;2;3]
What is it you're after?
Added by David Rutten at 8:59am on October 21, 2017
ersect (2, 3, 4, 5, 6) with the line and the ones which do not intersect (0, 1, 7). Intersect is done! But how to get the non intersecting vectors (0, 1, 7)?
So I e. g. could deselect vectors 2, 3, 4, 5, 6 so I would display/use only vectors 0, 1, 7 and the bounced ones.
Appreciate your help!
Rudi…
{4}-0;3
{5}-6;7
{6}-5;7
{7}-5;6
Here it can be shown that there are two subgraphs containing 0,1,2,3,4 and 5,6,7. How can I use spiderweb (either using scripting or the components) to give me this result when I have many more vertices??
Thanks,
Sam…
byte-accuracy red, green, blue channels) = 27 bytes. More likely 28 bytes as colours are probably stored as 32-bit integers, allowing for an unused alpha channel.
28 * 800,000 equals roughly 22 megabytes, which is way down from 9 gigabytes. That's a 400 fold memory overhead, which is pretty hefty.
Grasshopper stores points as instances of classes, so on 64-bit systems it actually takes 64+64+3*8 = 152 bytes per point*, which adds up to 122MB, still way less than 9GB. It would be interesting to know where all the memory goes...
* Grasshopper points also store reference data, in case they come from the Rhino document. This data will not exist, but even so it will require 64-bits of storage.…
Added by David Rutten at 4:13pm on December 11, 2014
shift. I realize I can use 'replace branch' but I do not have an available mask to utilize. I have simplified the problem to its simplest form so my question is understandable, however, the tree I am trying perform this operation on is a much larger 3 digit path address.
{1;3;2}
{2;3;4}
{3;5;4}
{4;3;7}
Change the above list to the list below.
{0;3;2}
{1;3;4}
{2;5:4}
{3;3;7}
I wish for a more robust arsenal of branch manipulation components. Most of the things I need to do are possible with the existing components, however, many operations take several components to perform even simple manipulations. Since branch/path manipulation is so integral to using GH successfully, it seems the GH community would be well served by enhancing the available path manipulation components.
Thanks,
Stan
…