On 6/24/24 09:29, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>>      double min = +-2.22507e-308
>>      double max = +-1.79769e+308
> 
> So, I just got done playing around with that 500+ lines of the hypergeometric
> function, and some of the values were too large to display in the #debug stream.
> 
> I had no idea I could - make - numbers that large in SDL.
> It looked like each line didn't carriage-return and overwrote the previous one.
> 

Unsure what you are seeing there. The windows output & official POV-Ray 
release for unix like systems are both long different than my yuqk fork 
in formatting and using '\r' (internally 'lf/cr' for one, I think. 
Though, it's been a long time since I've was making changes in that code)

The yuqk fork is unix/linux only and I moved everything to '\n' line 
terminations and formatting was made more compatible with typical 
unix/linux terminal output.

> Also, having objects with coordinates that large seemed to slow down the render
> phase even though the objects (small spheres) weren't even in the view frustum.
> I also sorta recall that some of my other spheres weren't even rendered, but
> that's a mid-debugging anecdotal eye-witness recollection - so assign to that
> whatever reliability that you will.
> 

See that previously attached file and the lines:

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.

I've since added more about bounding limits of +-2e10 and the max 
current intersection limit distance of +-1e7 which will be in the yuqk 
(R15) released version of that file.

> 
> So I'm wondering 3 things:
> 
> 1. how to make the #debug stream behave properly
>       (I often get things written to the stream that seem - out of order.)
>       no overwriting of existing lines when str() overflows the screen width

Fair answers in yuqk are to always use a trailing '\n' new line 
characters (and sometimes leading a leading '\n' ones help too to force 
'more immediate' outputs to particular streams. Set the inbuilt output 
streams to write each to files. Things are routed through POV-Ray's 
messaging system, which is itself buffered beyond any file buffering 
which, well just kinda get jumbled sometimes especially where POV-Ray's 
usual five output streams are getting merged in some way in the output 
users see.

One thing I do when I really care about debugging output is open an 
output file of my own and use "#write" with the newline '\n' character 
formatting to force more immediate output.

That file should be closed properly when you are done, but if you've 
added the newline '\n' characters the unix/linux OS is quite good at 
getting what's buffered written and closing the open file handles itself 
even when things crash.

> 2. how to use str () to display numbers to display with 10eN exponential format

There is no way to do this with str() or vstr() - it's on my list to 
look at numerical output issues with these too. Don't trust those string 
functions too far, if you do go beyond float ranges and accuracy.

One of the reasons I created the inbuilt function f_boom() was to get 
more accurate output including the jumps to exponential notation. Went 
to create a few examples - and blast it, if I didn't immediately see I'd 
used 16 digits instead of 17 in that function! The fix will be in R15 of 
yuqk.

> 3. how to express things like INF in SDL and write code to utilize that value.
> 

There is not today a way to directly use such literals in SDL, though I 
have given some thought to implementing a few like these in yuqk.

There may be some differences in results below depending on how your 
running version of was compiled. On linux using the default -ffast-math, 
-O3 optimized compile it should be you mostly follow as below.

Getting output with:  #debug concat("Val = ",str(Val,19,17),"\n")

#declare Val = -0.0;  // -0.0
#declare Val = +0.0;  //  0.0
#declare Val = 1.012345678901234567890/(+0.0); // +inf
#declare Val = 1.012345678901234567890/(+0.0); // +inf Why + ?
#declare Val =-1.012345678901234567890/0.0; // +inf Why + ?
#declare Val = -1.01e300/1e-300; // -inf

And using that last #declare you can use code like:

#if (Val < -1.01e300) // When Val -inf this trips...
     #debug "(Val < -1.01e300)\n\n"
#else
     #debug "\n"
#end

---

If in the SDL we have:

#declare Val = 1.012345678901234567890/1e-25;

The usual str() output will be:

10123456789012344763056128.00000000000000000

while yuqk's f_boom (with the 17 sig digit fix) spits out:

1.0123456789012345e+25  (and then it throws an exception)

Auto jumping to exponential notation should be done with str(), vstr() 
when we exceed double's representational  accuracy or the digits 
available due the user's formatting specification. Today we can create 
output with both noisy digits and garbage digits.

> Also, some of my macro results came back as NAN.  Doe yuqk have a function to
> assign NAN to a user-declared variable ?
> 

In my non-debug version of yuqk and my compile of v3.8 beta 2, you can 
get +-nan by calling one of the inbuilt functions (C++ std library 
functions) which generates them, but mostly they can only be be printed!

For example, numerical comparisons with them are not reliable (tangled 
in compiler options/support) and this is all that can be done in SDL today.

#declare Val = pow(-1,2.1);  // -nan

FWIW. The debug version of yuqk dies on the line above with:

Parse Error:
Domain error with pow() call.
Base value is negative and exponent not an integer.

Bill P.

Post a reply to this message