dak wrote
> Well, yeah. (* (/ ... h_inf) h_inf) does not make a whole lot of sense
> either way.
@Harm
Function F0_1(w) basically is supposed to return 0 for w = 0 and
asymptotically approach a limit of 1 as w grows wider.
Because atan(x) -> π/2 (i.e. 90°) as x -> infinity, the result is multiplied
by 2/π to get 1 as a limit.
h_inf is the maximum height the tie can reach.
Dividing by h_inf within the function just influences the shape of the
curve, i.e. how exactly F0_1 it will change from 0 to 1.
Finally, the result (!) of F0_1 is multiplied by h_inf.
In the current scheme code effectively (/ h_inf h_inf) gives a factor of 1
and has no effect at all.
The coding will work anyway, but the form of the curve will be different and
the maximum height will always be 1, no matter how big h_inf actually is.
*Therefore, your solution*
(* (F0_1 (/ (* w r_0) h_inf)) h_inf)))
*exactly matches the C implementation:*
Apart from that, either code will "work". As an example, I've plotted three
functions:
<http://lilypond.1069038.n5.nabble.com/file/t3887/bezier-tie-f0_1.png>
red: the "wrong" calculation with h_inf/h_inf = 1 cancelling out, no matter
what value you pass as h_inf
green: h_inf = 2, so that a maximum height of 2 is being approached.
green: h_inf = 3, so that a maximum height of 3 is being approached.
The "wrong" coding will always result in the red curve, as if h_inf was 1.
So if (incidentally) h_inf = 1, you won't see a difference.
All the best,
Torsten
--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
