Can somebody explain me the logic behind this ?
I was going crazy to understand why a circle has this behaviour
and Honestly for me its a bug
We are used to a circle domain (0- 2 pi) or (0.0 - 1.0)
The domain on a circle reports correctly (0 -2 pi )
but evaluate at parameter pi is not where you think.
Another strange behaviour, If you scale a circle the point at same parameter moves
to another position.
gd
Ok I have found the logic
The parameter p = radians x radius
A mystery for me , but Ok when You know
gd
The circumferece of a unit circle is
Evaluate Curve uses the length of the curve so
Alternatively you could also reparametrize the circle and use a domain from 0 to 1.00
Evaluate curve says “Evaluate at parameter”
and and You underlined the parameter domain is 0- 2 pi, and this is what gets printed
when You ask for the domain values.
The Length parameter is another domain where the parameter is the length (s) on the curve, this is not mentioned anywhere, the reason of my post
gd
The discrepancy is in the domain.
The domain of a line is 0 to length while a circle domain is basically just the angle domain in radians …
Why isn’t the circle domain 0 to length?
Good question 
Well Yes
Honestly I don’t like the curve domain to be from 0 to L
In a script environment I would prefer to think in terms of unitless parameters
0 - 1.0 (normalized) is the best choice (at least for me).
You never make stupid mistakes
gd
In most situations I’d reparametrize curves for evaluation
What I always do, just for the circle I got crazy since thinking in terms of angles
anyway
good to know for the future
gd
Parameter is not the angle in radians, you get the parameter from Curve closest point or from value in domain 0 to 1 when you reparametrize the curve.
That is true for a circular nurbs curve but not for arcs and circles. The parameter domain for a circular nurbs curve is 0 to L, where L is the length of the curve. The length is, of course the circumference so L = 2 x Pi x r, where r is the radius.
The parameter domain for a circle is 0 to 2*Pi. It does not take account of the radius. Thus the assertion that it is an angle is correct.
This is inconsistent with other curve domains and I would agree that it is technically a bug. The dilemma, of course, is that if this is how it has always been, and not just a recent blip, then “fixing” it will break countless grasshopper applications. 
Regards
Jeremy
The logic is described in the RhinoCommon API as:
Circles use trigonometric parameterization: t → center + cos(t) * radius * xaxis + sin(t) * radius * yaxis
Source:
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Circle_PointAt.htm
Sorry I am a bit stupid but cos(t) and sin(t) in that expression
means that the parameter is a angle in radians
but it seems its the arc length and not a angle (at least in the eval components)
gd
Yes I see what you mean. Using the Grasshopper Evaluate component on a non-unit circle doesn’t work as expected (i.e. having a 0.00-2*Pi domain). Calling Circle.PointAt or implementing the formula does work as expected though. For a normalised domain, you can always cast to curve and reparameterise it:
