I had at one point begun working on doing something along the lines of:

https://www.youtube.com/watch?v=dUkCgTOOpQ0

and that video came up in my YT feed, so I resumed dabbling with it.

Clearly there were potential problems with graphing line segments at certain
angular values where numerical values would be 0 or Inf.

It appears that at 90 degrees (pi/2), tan and sec do not equal Inf.
so
#declare csc = function (N) {select (sin(N), 1/sin(N), Inf, 1/sin(N))}
failed.
I had to test against 1E10.

[The function parser does not like val ("inf"), and so I initially had to
#declare Inf=val("inf");]

Also cylinder {<cos(Angle), sin(Angle), 0>, <Radius*sec(Angle), 0, 0> ...
gave some wild results - probably due to some kind of floating point overflow.
Though it doesn't really explain why the starting point was in entirely the
wrong place...   Hmmm....   Worrisome.

Pausing this again due to the late hour.
I am wondering if there are any ideas for good workarounds to make going around
the full circle hiccup-free.

Things like the tangent line endpoint jumping from y=0 to y=1 at inf provoke
some thought.  Perhaps there's a method that cleverly uses geometric inversion.

At any rate, this is sure to find plenty of bugs / undesirable digital math
behaviour that needs fixing / working around.

- BW

Post a reply to this message

On 2025-10-15 22:22 (-4), Bald Eagle wrote:
> 
> It appears that at 90 degrees (pi/2), tan and sec do not equal Inf.
> so
> #declare csc = function (N) {select (sin(N), 1/sin(N), Inf, 1/sin(N))}
> failed.
> I had to test against 1E10.

This isn't so much a bug as a floating point limitation.  Pi/2 has no
exact representation in binary, so you never get exactly 90 degrees.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> This isn't so much a bug as a floating point limitation.  Pi/2 has no
> exact representation in binary, so you never get exactly 90 degrees.

I figured it was something along those lines -

which is why I was attempting a quick experimental workaround with select ().

However:  I was looking at it from the perspective of it being a "bug" since
there might be sufficient user expectation for - something - to massage that
little wrinkle so it doesn't affect the end result so drastically.

I was just wondering if perhaps there were other software packages or algorithms
to addrress the issue.

It also doesn't explain why the left endpoint gets moved significantly down and
to the left, when it's the value of the right endpoint that's experiencing the
numerical issue.

And that's where I think I've discovered a REAL bug in the computation of the
cylinder.



- BW

Post a reply to this message

Attachments:
Download 'trigfunctions.png' (58 KB)

Preview of image 'trigfunctions.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
> > This isn't so much a bug as a floating point limitation.  Pi/2 has no
> > exact representation in binary, so you never get exactly 90 degrees.

And following along with that:   how do we then calculate cos (pi/2) and get
exactly 0, or sin (pi/2) and get 1?

Can we ever get exactly pi/2?  Pi?  3pi/2?  2pi?

Also when I was testing at theta=0, I was getting Inf for csc(Theta).
It just seems to me that basic unit circle functions ought to be implemented
well enough to handle the complementary situation at Theta=pi/2.

I don't have access to the parser for another 8h, so perhaps someone can run a
few loops to spit out values, or investigate the cylinder rendering issue.

- BW

Post a reply to this message