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
are on their own paths, but the first branch contains 3 curves and the second one 2 curves. If you want the same result for all pairs of curves you'd need to split up the first and second branches, so that all curves are on their own branch.…
Added by Lars Renklint at 4:33am on September 6, 2009
ggle A
7. Toggle A
8. Toggle 2
9. Toggle 3
10. Toggle A
11. Toggle A
12. Toggle 3
I was thinking to use somehow slider and animate option....but without luck
Any idea would be appreciated…
ve a Vertex [V] connected to four other Vertexs [N1-N4].
Each of the has a Value:
V ... 1
N1 ... 5
N2 ... 3
N3 ... 8
N4 ... 11
The Average Filter would set the Value of [V] to
(1+5+3+8+11)/5 = 5,6
The Median Filter would Sort Values and pick the middle one
1,3, [5], 8, 11
Hope that helped...…
e input says that a value of 12 should equal 12 PM, but it seems to be showing 11 AM instead. I checked this against Diva, in case I had just forgotten how to read a sun path diagram :P I've attached the sunpath from ladybug and diva, both were set to June 21 at 12 pm. As you can see Ladybug is one hour earlier. Seems to be a bug, and can be dealt with by simply changing the inputs to account for it, but it's misleading that the input says one thing and does another.
Thanks!…
ber of mesh vertices is defined as (precision_+1)^2.So if you would like to have its beam, diffuse and ground-reflected components as well, that means 3 * 8760 values per single point.Example: if you set your precision_ input to 20, the number of values would be a couple of millions:
(20+1)^2 * 8760 * 3 = 11 589 480 hourly values
Check the attached definition below. The outputs that you need are: "Ebeam", "Ediffuse", "Eground".They contain annual hourly values for each tilt and azimuth combination (that's what upper mesh vertices represent) in a data tree.…
pen Brep"; I didn't know it worked on flat surfaces. And I think it's only fair to include in your benchmark the considerable time 'SUnion' takes in this example: 21.9 seconds for 121 rings and likely much more with 400 or 1,000+ rings.
Then I noticed the pattern doesn't match. Checked the circles and they are the same. The distance between them, however, is different: 7 instead of 6. When I change that value to 6, the Python fails badly. All the holes and gaps are gone, which destroys the pattern:
I can't do the "two phase" approach on an 11 X 11 grid, but I can do 6 X 6 and 2 X 2 to get a 12 X 12 grid (40 'SUnion' operations) in 28 seconds total. That beats your benchmark of ~37 seconds for an 11 X 11 grid, if you include the 'SUnion' in your code.
…