"Kelumden" <nomail@nomail> wrote:

> In your interpretation, Y will never be incremented ...

Yes, I knew there was reason that I wasn't fully confident with what I wrote.

Thanks for the clarification - I was trying to crank out a language translation
at the end of a hot day, and getting frustrated by parser woes.

Thanks!

Hopefully I can get the rest of it sorted out to do some testing and then start
daisy-chaining everything together soon.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> then 3.1
> which is when it started parsing differently / more thoroughly.

noted.  (for when it's my turn again "cursing the parser" :-))


> Hope you're doing well and staying cool,

the "heat dome" your side is making the news here too, hope you too (and WFP,
others? in the region) keep cool + hydrated.  cheers.

regards, jr.

Post a reply to this message

On 6/21/24 05:40, Bald Eagle wrote:
>> 1)
>>    Result
>>
>>           #end // end macro Gamma
>> #end
>>
>> Those lines should be:
>>
>>           #end
>>   Result
>> #end // end macro Gamma
> That's because I left that extra #end in there to just try to get it to run
> without complaining about the initial "missing" #end statement.

To my eyes and a quick check the parser was correct to complain. Without 
that 'extra' #end you have a missing #end statement in the code you 
posted. That 'extra' one fixed that, but Result ended up in the wrong 
spot - about which the compiler is also right to complain.

I agree though, the error message is confusing. In my yuqk fork, I can 
add another line of explanation making the entire error message:

Parse Error:
#declare of float, vector, and color identifiers require semi-colon ';' 
at end. As do equivalent #local identifier definitions and the #version 
setting. This error is sometimes issued where an #end statement 
incorrectly follows a floating, defined identifier. The problem may 
involve lines of prior code.

Is that error message more helpful?

I see Kelumden answered your C++ question (Thank you). Apologies. I 
spaced that you'd asked it.

---

I'll offer up two tricks I use. One when translating from c/C++ to SDL 
or playing with potential changes to the POV-Ray(yuqk) code base. The 
other when trying to match all of SDL's opening directive blocks with 
their #end(s).

1) For smallish questions about c/C++ code, compile and run a small 
example. The whole of the recently announced f_catenary() function was 
written this way prior to inserting it into the yuqk source code. 
Install a C++ compiler if you've not.

For the question you asked, I'd create a file my.cpp containing:

//---
#include <iostream>
#include <string>

int main()
{
     double Result = 1.0;
     int    Y      = 1;

     Result *= Y++;
     std::cout << std::endl << Result << std::endl;

     Result *= Y++;
     std::cout << std::endl << Result << std::endl << std::endl;
}
//---

Compile with:

	g++ my.cpp

or equivalent. Without setting more options, the executable on unix like 
systems will be 'a.out'. In a terminal window type:

	a.out

And you'll see:

1

2

Trying ++Y is an interesting experiment too.

2) When really stumped on #end matching, employ an editor which matches 
braces, parens, brackets or the like. It doesn't need to be the editor 
you use day to day. I'm using 'vim via gvim' on my Ubuntu machine.

Edit a temporary file called my.pov. I started by boiling the code you 
posted for Gamma() down to what needs #end matching. I then added open 
'{' and close '}' characters in a more or less outside -> inward order.

#macro Gamma (X) {
     #if (X <= 0.0) {
     #end }

     #if (X < 0.001) {
     #end }

     #if (X < 12.0) {
         #if (arg_was_less_than_one) {
         } #else {
         #end }

         #for (i, 0, 7) {
         #end }

         #if (arg_was_less_than_one) {
         } #else {
             #for (i, 0, n) {
             #end }
         #end }

         #if (X > 171.624) {
         #end }
     #end }
#end }

When lucky, mistakes will immediately be highlighted in red. When not - 
say, for example, #end(s) are in some way matching incorrectly - I place 
the cursor at each opening '{' or closing '}' brace in turn. Its 
matching brace will be highlighted(*) in a like color to the one at my 
cursor - and I check that matching is correct for each matching pair in 
turn.

Yes, I'm managing to stay cool, but one sure feels the heat & humidity 
on stepping outside! :-)

Bill P.

(*) - In larger bits of code there are ways to find and move to the 
currently matching brace.

Post a reply to this message

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


> To my eyes and a quick check the parser was correct to complain. Without
> that 'extra' #end you have a missing #end statement in the code you
> posted. That 'extra' one fixed that, but Result ended up in the wrong
> spot - about which the compiler is also right to complain.

Ugh.  I really must have been reading straight through something.
I'll go over it again ASAP and try to see what I was missing.


> Parse Error:
> #declare of float, vector, and color identifiers require semi-colon ';'
> at end. As do equivalent #local identifier definitions and the #version
> setting. This error is sometimes issued where an #end statement
> incorrectly follows a floating, defined identifier. The problem may
> involve lines of prior code.
>
> Is that error message more helpful?

Better.  I'll have to read that again when I'm encountering it during my
testing/editing.

> I see Kelumden answered your C++ question (Thank you). Apologies. I
> spaced that you'd asked it.

Totally fine.   I constantly have things drop off the stack when I'm trying to
compose a long list of ideas and/or responses.

> 2) When really stumped on #end matching,
 . . .
> When lucky, mistakes will immediately be highlighted in red.

I will try some version of that - thanks!

 - BW

Post a reply to this message

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