POV-Ray : Newsgroups : povray.general : f_helix documentation is wrong : Re: f_helix documentation is wrong Server Time
5 Jul 2024 11:30:42 EDT (-0400)
  Re: f_helix documentation is wrong  
From: Anthony D  Baye
Date: 11 Dec 2014 18:25:00
Message: <web.548a23cf1be1f4461538d4890@news.povray.org>
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> "omniverse" <omn### [at] charternet> wrote:
> > "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> > > f_helix1(x,y,z,n,p,r,R,s,c,a)
> > > supposedly, the fifth parameter is the period, or "Number of turns per unit
> > > length".
> > >
> > > The way I read this is that, for every unit the helix object rises, it should
> > > make one complete turn.  This is obviously not the case.
> >
> > Anthony, I can confirm same here.
> >
> > Slightly different wording found in the Insert menu, Special shapes|Isosurfaces
> > by function.inc and placing the Isosurface f_helix into a scene file, so I went
> > looking for the source code after realizing it was essentially saying the number
> > of turns is based on a complete circle. Meaning if you apply that 2*pi to your
> > number of turns you should get what you expected. I checked this and seemed to
> > work.
> >
> > Source code makes very little sense to me, although a coding math wizard
> > probably could get the 2*pi introduced into there somehow.
> >
> The source makes very little sense, period.  I tried tracing the path for the
> command line options to find out the answer for another question, and I couldn't
> figure out where anything was handled.
>
> I found references to several apparently different functions called "trace" but
> nowhere could I find definitions or forward declarations for them. (I downloaded
> the zip of the master and went through it using grep)
>
> It would make more sense -to me, at least- for command line parsing to be more
> centralized, with options and their values stored in a dictionary that could be
> queried by various modules, but that's just my opinion.  It may be that there
> would be some undesirable overhead in that method, but it would seem to me that
> maintainability would win out.
>
> At any rate, it makes no sense for the period of a helix to be based on length
> of the curve.  Could something have gotten mixed up between this and the
> toroidal form?

Or it could be based on the math for a helicoid:
http://mathworld.wolfram.com/Helicoid.html

since it doesn't seem to maintain its shape very well w/r/t different parameters
for min and max radius.  Wouldn't it be better to plot the shape in the
normal plane? http://mathworld.wolfram.com/Helix.html

See: osculating plane -> normal plane

Keep in mind that my math skills aren't stellar.  Some things I can keep up
with. Others, not so much.

Regards,
A.D.B.

P.S. more comments in the code would help.  Not every programmer is a math
genius. My programming instructors would have docked me letter grades. (I'm not
trying to start a flame war here or point fingers.  I know this codebase was
written by a lot of different people over quite a long time, and I understand
that cleanup is an ongoing process.)

http://yarenty.blogspot.com/2014/03/pants-on-fire-9-lies-that-programmers.html
I'm guilty of a few of these.

A.D.B.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.