> What is the smallest number that I can realistically use for a variable value?
> Largest?
>
> (Maybe yuqk can have yuqk_smallest and yuqk_largest as internal values to
> compare against?)


The fine print first (Disclaimers)
----------------------------------

The safe answer is I don't know for the code you with which you are working.
It depends on the maths involved. If using the calculated results in
downstream (or from upstream) POV-Ray functionality, it sometimes depends on
what that functionality is.

The math within parser's Scene Description Language (SDL) is different than
the where shapes, functions and ray tracing are involved.

The yuqk fork is different numerically than is the official POV-Ray code base.
For one, it much more often uses double as the pass around, working float
representation. Yuqk uses two 'epsilon' values internally where the POV-Ray code
base uses one, more generic 'epsilon' value.

Floating point math can be a wild ride no matter POV-Ray / yuqk fork
specifics.


Guidelines
----------

When working within the Scene Description Language (SDL)
--------------------------------------------------------

The SDL identifiers / variables are at double accuracy for single values and
vector values of sizes 2 through 4. The 5D vector is always a color vector at
float accuracy. Language constants like 'pi' are at double accuracy.

Where values are passed through POV-Ray's internal messaging system, doubles
are cast to floats in official releases of POV-Ray. The yuqk fork maintains
the double representation.

Small value
-----------

Where you need a small value in official releases of POV-Ray sticking with
the 1e-10 value recommended by:

    https://wiki.povray.org/content/Reference:Numeric_Expressions

is a good rule of thumb. This is the single EPSILON value the official source
code uses internally.

With the yuqk fork there are two small values internally. One for testing
for effective zero values or effective equivalent values called gkDBL_epsilon.
Another larger value is used where one might be using solvers, or heavier
math functions like sqrt(), it is called gkMinIsectDepthReturned.

Currently these are set to:

    gkDBL_epsilon           = 4.44089e-16
    gkMinIsectDepthReturned = 4.44089e-08

Examples:

    #if (abs(A-B)<gkDBL_epsilon)
        #debug "A and B are equal"
    #else
        #debug "A and B are not equal\n"
    #end

    #if (abs(A)<gkDBL_epsilon)
        #debug "A is zero"
    #else
        #debug "A is not zero\n"
    #end

Large (extreme) value range
---------------------------

So long as the maths are entirely within the SDL/VM/Messaging framework in the
yuqk fork, you can use the double's range of values:

    double min = +-2.22507e-308
    double max = +-1.79769e+308

In official POV-Ray releases - or where you want to play things safer to home
in yuqk - using the single float ranges are more stable / reliable.

    float min = +-1.17549e-38
    float max = +-3.40282e+38


When working with shapes and functions defining shapes
------------------------------------------------------

In official releases of POV-Ray a good rule of thumb is to keep coordinates,
shape dimensions, spatial transforms and values in the 1e-2 to 1e+5 range.

The yuqk fork supports a more centered 1e-6 to 1e+6 range.

Again it's a rule of thumb float value range many exceptions apply depending
on the features in play. You can do much better or much worse. The ray's
travel distance to and between intersection plays a big part in the achievable
numerical accuracy for many shapes. Internally bounded shapes like isosurfaces
are more stable in this respect due the low order contained by shapes being
spheres and boxes (ray distances matter less).


Numerical exceptions
--------------------

Official releases of POV-Ray, and the yuqk fork's daily use / performance
release, do little checking for exceptions. True especially with unix/linux
compiles using -ffast-math. If something goes wrong, often there will be no
notice beyond something not rendering / working correctly as percieved by the
user. Most all standard math functions are really C++ equivalents. It's good
to understand their numerical limitations.

For debugging, the yuqk fork supports a debug compile which turns on a great
deal more self checking. The debug compile is slow, but if something seems
amiss, running the debug compile of the yuqk fork can often point to the
problem.