It is the parameter that starts the segment you want to get the radius for.
This is a utility routine that is used by other routines, and they only made the call as they "walked the polyline". Therefore, in my code, it was always being called with a value that was an even integer (i.e., a parameter at a polyline vertex), even though the type is a double. So I suspect I should change my code to use a cast to an int, yielding a truncation, rather than the Convert.Int32, which rounds the value. Since my code never calls this routine with anything but integer values, I didn't notice this problem.
This routine is now part of my SincpacC3D's CurveUtil class, but I think it's a recent addition that isn't in the version posted to the web page. I'm almost done with a major revamp of the SincpacC3D, and once it hits a relatively-stable point again, I'll post a new version of the source code that contains the revamped library classes. The bulk of the new SincpacC3D commands will remain proprietary this time around, but I plan on releasing the base AutocadUtilites and Civil3DUtilities under a completely free license. Eventually, I hope to break that out into a full-fledged free Autocad/Civil-3D SDK that removes much of the time-consuming "grunge" involved with working with Autodesk's low-level APIs.
And thanks for the update, Daniel... I think I'll take what you did, and expand it a little. Right now, there is no real test for a line segment. Basically, for a line segment, the function returns a RadiusPoint with Radius==0. I'd rather add an explicit flag for this, rather than having code which checks for Radius==0, which is kind of ambiguous.