I was really just going mind-blind.

I went over that code another 7 or 8 times and still missed it.
I even skipped over the (obvious in hindsight) spot where the indenting skipped
a beat.

"I started by boiling the code you
posted for Gamma() down to what needs #end matching."

So I did that, and I caught it.
#if (X < 12.0) was not properly ended.

Got it to mostly work.
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?)

I know Alain posted this somewhere, but trying to find it....

I'm gonna get some sleep and then see if writing a Beta function works with what
I've got for Gamma.


Thanks.  Sanity mostly restored.
Also poured for 2 days, so a lot cooler.

- BW

Post a reply to this message

On 6/21/24 22:16, Bald Eagle wrote:
> Got it to mostly work.
> 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?)

With respect to SDL variables, your asking a simple sounding, 
complicated question. :-)

Let me think about what a good answer would be.

I too have thought about bringing out some of the internal values used 
in yuqk - through a new function or new keywords. There are a couple 
good numeric rules of thumb used internally in the yuqk fork. The 
official releases of POV-Ray are ... more chaotic, numerically.

Bill P.

Post a reply to this message

On 6/22/24 01:58, William F Pokorny wrote:
> With respect to SDL variables, your asking a simple sounding, 
> complicated question. 🙂
> 
> Let me think about what a good answer would be.

OK. I've written up a first draft of documentation I plan to include in 
the next yuqk release (R15). See the attached txt file.

Bill P.

Post a reply to this message

Attachments:
Download 'rulesofthumbformath.txt' (5 KB)

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/22/24 01:58, William F Pokorny wrote:
> > With respect to SDL variables, your asking a simple sounding,
> > complicated question. 🙂
> >
> > Let me think about what a good answer would be.
>
> OK. I've written up a first draft of documentation I plan to include in
> the next yuqk release (R15). See the attached txt file.
>
> Bill P.

Thank you for this.  :)



"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
"

:O   Holy crap.

"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
"

WAY more range than I thought there was!

So values of 10^-16 shouldn't be too big of a deal.

- BW

Post a reply to this message

"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.

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.



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
2. how to use str () to display numbers to display with 10eN exponential format
3. how to express things like INF in SDL and write code to utilize that value.

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

- BW

Post a reply to this message

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

On 6/24/24 20:30, William F Pokorny wrote:
> #declare Val = 1.012345678901234567890/(+0.0); // +inf Why + ?

Should have read:

#declare Val = 1.012345678901234567890/(-0.0); // +inf Why + ?

---

FWIW. This morning I glanced at the str() implementation while my coffee 
maker worked. You can on overflowing an internal buffer, trigger 
exponential (%g) formatting, but that method is of course not of 
practical use...

---

I also forgot, as I often do because of its name, about our val() SDL 
function which converts string floating point representations of values 
to internal double representations. The following works, which could be 
useful for +-inf maths.

#debug concat("val(\"+inf\") = ",str(val("+inf"),19,17),"\n")
#debug concat("val(\"-inf\") = ",str(val("-inf"),19,17),"\n")
#debug concat("val(\"+nan\") = ",str(val("+nan"),19,17),"\n")
#debug concat("val(\"-nan\") = ",str(val("-nan"),19,17),"\n")

---

Aside. I've have avoided putting much work into the SDL string functions 
in yuqk because I want to do that work alongside a move to all utf8 
string handling (with conversions to ucs4 internally for things like 
strlen(), maybe message passing too, I don't know - all at that dream 
planning stage).

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> I also forgot, as I often do because of its name, about our val() SDL
> function which converts string floating point representations of values
> to internal double representations. The following works, which could be
> useful for +-inf maths.
>
> #debug concat("val(\"+inf\") = ",str(val("+inf"),19,17),"\n")
> #debug concat("val(\"-inf\") = ",str(val("-inf"),19,17),"\n")
> #debug concat("val(\"+nan\") = ",str(val("+nan"),19,17),"\n")
> #debug concat("val(\"-nan\") = ",str(val("-nan"),19,17),"\n")

Whoa.  This is interesting.
I don't currently have access to a machine to run the test with, but:
Can we use those for actual practical comparisons?

#if (N = "val(\"+inf\") )
.. . .
?

#if (N = "val(\"+nan\") )
.. . .
?

And are the signs required?

- BW

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I also forgot, as I often do because of its name, about our val() SDL
> function which converts string floating point representations of values
> to internal double representations.

"our" as in not just 'yuqk' ?  (because the wiki docs only mention 'float', and
knowing it'll be a double is useful (I think))


regards, jr.

Post a reply to this message

On 6/25/24 09:45, Bald Eagle wrote:
> Can we use those for actual practical comparisons?

Unless there is some sort of bug(*) or check(**) it should be you can do 
comparisons with inf (the sign should only be strictly needed for -inf).

Bill P.

(*) - There might be compiler flags which break the capability - see 
recent povray.unix posts. Testing what you expect to work involving 
+-inf in SDL is prudent. I'd not trust feeding these infinite values to 
functions SDL or VM ones for example.

(**) - The debug compile of the yuqk fork will often, but not always 
complain and stop/throw on seeing infinite values.

Post a reply to this message