I was playing with Splines using 'VPerp_To_Vector' & 'vaxis_rotate' to fill
arrays that made a spline. Then using a 'for' loop & the spline to place lots of
spheres.
The trouble started when <0,0,0> was used accidentally as input for the above.
'VPerp_To_Vector' returns <0,0,0>
'vaxis_rotate' returns <-1.#IO,-1.#IO,-1.#IO>
Or at less this is what POV prints out when checked.

What was strange is that there never was an error when using the spline, it just
didn't show any spheres or a few at the ends.

#if(V2=<-1.#IO,-1.#IO,-1.#IO>) #debug"hit"#end

Caused POV to Crash!

This was on version 3.7.0.msvc10.win64
And my computer: Window10
Processor Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz   3.30 GHz
Installed RAM 32.0 GB


Have Fun!

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:

> 'vaxis_rotate' returns <-1.#IO,-1.#IO,-1.#IO>
> Or at less this is what POV prints out when checked.

Yeah, that's pretty crazy.
I've never even heard of that notation!

https://stackoverflow.com/questions/18249065/lua-file-output-what-is-1-io

> What was strange is that there never was an error when using the spline, it just
> didn't show any spheres or a few at the ends.

I'm guessing POV-Ray must have some sort of internal error handling for division
by zero / infinite values, and just runs with it.  That's not to say that what
you're doing will render correctly, as I observed with my trig scene.


> #if(V2=<-1.#IO,-1.#IO,-1.#IO>) #debug"hit"#end
>
> Caused POV to Crash!

That's weird - might be something that the parser doesn't handle well, but
crashing isn't acceptable.  Try -Inf

Also submit a bug report.


Does #if(V2.x =-1.#IO) cause a crash?

I'd run some similar experiments with inf, nan, etc. to see what happens

To get your scene to run, I'd test against some "very large value" and
early-exit if your value is greater than that.

- BE

Post a reply to this message

Following up,

It looks like this is a general "undefined" state for Windows.
My money is divide by zero error in normalizing the vector to unit length.

https://www.mathworks.com/matlabcentral/answers/31571-1-io-error-on-xpc

https://stackoverflow.com/questions/35997187/what-leads-to-the-floating-point-exception-1-io

https://www.sierrachart.com/SupportBoard.php?ThreadID=14054

https://unmethours.com/question/24410/-1io-error-value-when-running-battery-storage-in-e/

I'd simply check vlength (Vector) before proceeding, and exit early if a
zero-length vector is the input.

(Using those values in a #if statement should still not crash POV-Ray)


- BE

Post a reply to this message

that shows up when you print a special floating‑point value (like infinity
or NaN) with certain precisions; the classic strings 1.#INF (infinity) or 1.#IND
(indeterminate/NaN) get mangled to 1.#IO. In other words, if you see 1.#IO, your
number was almost certainly infinite or not‑a‑number, and the way it

[stackoverflow.com], [blog.csdn.net]

What it actually represents
On Windows, the C runtime historically prints special floating‑point
values like this:



such as 0.0/0.0, sqrt(-1), etc. [stackoverflow.com], [johndcook.com]

[stackoverflow.com]

When you format those with certain precisions (e.g., printf("%.3f", x) or
fixed/scientific iostream manipulators), the internal #INF / #IND text can be
truncated/rounded into #IO. Demonstrations of %.3f producing -1.#IO and of
iostream precision turning 1.#INF into 1.#IO are documented and reproducible.
[stackoverflow.com], [blog.csdn.net]

or NaN detected in your computation. [stackoverflow.com], [johndcook.com]

Typical causes (why you got it)
These usually create INF or NaN, which may print as #IO:

Division by zero (1.0/0.0 → +INF, -1.0/0.0 → -INF, 0.0/0.0 →
NaN). [johndcook.com]
Domain errors: sqrt(-1), log(-1), etc. → NaN. [johndcook.com]
Overflow to values too large for float/double → INF. [stackoverflow.com]
Formatting quirks with fixed precision or certain format specifiers (%.3f,
std::fixed << setprecision(3)), which turn #INF/#IND into #IO.
[stackoverflow.com], [blog.csdn.net]


How to detect and handle it correctly
Instead of relying on printed text, test the value:

C/C++ standard checks: std::isnan(x), std::isinf(x), std::fpclassify(x).
[en.cppreference.com]
MSVC‑specific: _isnan(x), _fpclass(x) (legacy). [learn.microsoft.com]

Example (C++):
C++#include <cmath>      // std::isnan, std::isinf, std::fpclassify#include
<iostream>void print_safe(double x) {       if (std::isnan(x))       std::cout
<< "NaN\n";    else if (std::isinf(x))  std::cout << (x > 0 ? "+INF\n" :
"-INF\n");    else                     std::cout << x << "\n";Show more lines
(Functions and behavior documented in the C/C++ libraries.)
[en.cppreference.com]

Practical tips (to avoid seeing 1.#IO)

Fix the math: guard against zero denominators and invalid domains; clamp inputs;
use safer formulations. (These are the root causes of INF/NaN.) [johndcook.com]
Change formatting: use %g or std::defaultfloat so special values print as

shown above. [en.cppreference.com]
Diagnose quickly: add checks after any risky operation (division, sqrt/log,




If you saw it in POV‑Ray output
POV‑Ray on Windows uses the same CRT for text formatting; if you emit
values (e.g., via #debug or write to a file) with fixed precision, 1.#IO can
appear when your scene math hits INF/NaN. The remedy is the same: guard your
calculations and test for isnan/isinf in any helper code before printing; or
change the format to avoid the mangled representation. (General CRT behavior and
formatting issues apply.) [en.cppreference.com], [stackoverflow.com]

- BE

Post a reply to this message

Also check out:
https://www.johndcook.com/IEEE_exceptions_in_cpp.html

(I read a lot of John's blog posts - it's very interesting and informative)



Testing for NaNs and infinities
Next suppose you want to test whether a number is an infinity or a NaN. For
example, you may want to write to a log file print a debug message when a
numerical result goes bad, or you may want to execute some sort of alternate
logic in your code. There are simple, portable ways to get summary information
and more complicated, less portable ways to get more information.

First, the simple solution. If you want to test whether a double variable
contains a valid number, you can check whether x == x. This looks like it should
always be true, but it's not! Ordinary numbers always equal themselves, but NaNs
do not. I've used this trick on Windows, Linux, and Mac OSX. If you ever use
this trick, put big bold comments around your code so that some well-meaning
person won't come behind you and delete what he or she things is useless code.
Better yet, put the test in a well-documented function in a library that has
controlled access. The following function will test whether x is a (possibly
infinite) number.


    bool IsNumber(double x)
    {
        // This looks like it should always be true,
        // but it's false if x is a NaN.
        return (x == x);
    }

To test whether a variable contains a finite number, (i.e. not a NaN and not an
infinity) you can use code like the following.


    bool IsFiniteNumber(double x)
    {
        return (x <= DBL_MAX && x >= -DBL_MAX);
    }

Here DBL_MAX is a constant defined in float.h as the largest double that can be
represented. Comparisons with NaNs always fail, even when comparing to
themselves, and so the test above will fail for a NaN. If x is not a NaN but is
infinite, one of the two tests will fail depending on whether it is a positive
infinity or negative infinity.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:

> > #if(V2=<-1.#IO,-1.#IO,-1.#IO>) #debug"hit"#end
> >
> > Caused POV to Crash!
>
> That's weird - might be something that the parser doesn't handle well, but
> crashing isn't acceptable.  Try -Inf

Looks like it's likely a parser / tokenizer issue.

Also, when comparing vectors, use
VEq(V1, V2). Tests for equal vectors, returns true if all three components of
V1equal the respective components of V2.

(IIRC, that's in math.inc)




# characters. [wiki.povray.org], [cmp.felk.cvut.cz], [POV-Ray 3....n Page 93.]
In POV‑Ray, # is reserved to start language directives (e.g., #if,
#declare, #include). When the scanner encounters -1.#IO, it reads -1. as a


instead of producing a normal parse error. [povray.org], [POV-Ray: D...n
Language]



The condition #if (V2 = <...>) is being treated as a relational equality test
(=) inside the #if (not an assignment). #if conditions must evaluate to a


in the numeric token, but even with valid numbers you would need to compare
vectors via their components or length. [museum.state.il.us], [wiki.povray.org]

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Following up,
>
> It looks like this is a general "undefined" state for Windows.
> My money is divide by zero error in normalizing the vector to unit length.
>
I agree.


> https://www.mathworks.com/matlabcentral/answers/31571-1-io-error-on-xpc
>
>
https://stackoverflow.com/questions/35997187/what-leads-to-the-floating-point-exception-1-io
>
> https://www.sierrachart.com/SupportBoard.php?ThreadID=14054
>
>
https://unmethours.com/question/24410/-1io-error-value-when-running-battery-storage-in-e/
>
> I'd simply check vlength (Vector) before proceeding, and exit early if a
> zero-length vector is the input.
>
Yea! That's what I did before I posted here. I just never seen -1.#IO before.
And the spline behavior through me. I thought I'd at less get an error saying
don't do that.

> (Using those values in a #if statement should still not crash POV-Ray)
>
Today I tried again to make it crash. And of course it didn't. All I get is :
Parse Error: Expected 'numeric expression', undeclared identifier 'IO' found
instead
Your second link here may have the answer. It said :

"That -1.#IO propogates to all of the other subroutines so eventually I have
thousands of variables with this exception before it blows up"

I did have my first test at the end of the file I was working on.

Have Fun!

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Leroy" <whe### [at] gmailcom> wrote:
>
> > > #if(V2=<-1.#IO,-1.#IO,-1.#IO>) #debug"hit"#end
> > >
> > > Caused POV to Crash!
> >
> > That's weird - might be something that the parser doesn't handle well, but
> > crashing isn't acceptable.  Try -Inf
>
> Looks like it's likely a parser / tokenizer issue.
>

That statement never should have been tested. I was just moving to fast to
notice what I was doing. I got into the habit of typing away, hit RUN and fix
the errors that come. But this error caused it to crash!

 I did go back and test '#if(V2.x=V2.x) #debug"hit\n" #end' after I load V2 with
-1.#IO by using vaxis_rotate(<0,0,0>,<0,0,0>,35).

And I got a Hit!

Have Fun!

Post a reply to this message