I'm trying to port some c++ over to SDL so that I can use the Gamma function to
implement the version of the Beta function based on that.

original code:
https://www.johndcook.com/Gamma.cpp

Using v 3.8, I get "end of file found, but #end expected" even though I went
through the code 7+ times and every opening statement was matched with a
corresponding #end.

So I added a token #end, and got an error that it didn't recognize TestGamma,
which is a macro name.

So I set the scene to v 3.5 and got a bunch of weird ; errors
and now it's not recognizing #local declared variables.

This parser has some major problems if I can't write some simple macros.

Can anyone confirm?
debug?
provide a sane and function workaround?

- BW

PS


Also struggling a bit with
result *= y++;
I interpreted that as:
#local Result = Result * (Y+1);
(line 102)

Post a reply to this message

Attachments:
Download 'gamma.pov.txt' (8 KB)

On 6/20/24 19:49, Bald Eagle wrote:
> Can anyone confirm?
> debug?

I see a few things.

The yuqk fork complains about the line with the comment "// end macro 
Gamma" and there being a missing semicolon somewhere prior, but in this 
case the error is somewhat miss-leading.

The parser is unhappy because that line isn't the end of the macro, but 
of an #if directive. The '#end' line following is the end of the macro.

1)
		Result

         #end // end macro Gamma
#end

Those lines should be:

         #end
	Result
#end // end macro Gamma

2) Also in macro Gamma it looks possible by logic to go all the way 
through that macro and not ever set Result. So my strong recommendation 
would be to immediately set a default local 'Result' value at the top of 
Gamma(), but I don't know what it should be.

3) Also in macro Gamma you have:

      #if (X <= 0.0)
         #warning concat ("Invalid input argument ", str (X, 0, 4),
		". Argument must be positive. \n")
         #break
     #end

But, seems like that needs to be an #error as your not handling Result 
on the #break. You could not do that check at all then below cheat 
around some potential divisions by zero by adding fudge factors but I 
have no immediate idea what this means for the validity of any result.

     #if (X < 0.001)
         #local Result = 1.0/((X*(1.0 + _gamma*X))+1e-6);
     #end

and

     #local Result = Result / ((Y-1.0) + 1e-6);

4) The following line needs a semicolon:

#local Test = Gamma (0.5)

5) In TestGamma() you have the line:

#local computed = Gamma (test[T][0])

which needs a semicolon.

I hope of some help.

Bill P.

Post a reply to this message

hi,


William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/20/24 19:49, Bald Eagle wrote:
> > Can anyone confirm?
> > debug?
>
> I see a few things.

and _then_ there's the first line:
> #version 3.1;

</grin>


regards, jr.

Post a reply to this message

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

> The yuqk fork complains about the line with the comment "// end macro
> Gamma" and there being a missing semicolon somewhere prior, but in this
> case the error is somewhat miss-leading.
>
> The parser is unhappy because that line isn't the end of the macro, but
> of an #if directive. The '#end' line following is the end of the macro.
>
> 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.

The initial configuration was just:

  Result

#end // end macro Gamma


Then I just commented it out when I started version changing.

> 2) Also in macro Gamma it looks possible by logic to go all the way
> through that macro and not ever set Result. So my strong recommendation
> would be to immediately set a default local 'Result' value at the top of
> Gamma(), but I don't know what it should be.

Yes, I had that sort of idea in the back of my head after I converted to SDL,
but without being able to run it and test it, that hardly matters.  I'd get an
obvious Lvalue Rvalue error of some sort anyway.

> 3) Also in macro Gamma you have:
>
>       #if (X <= 0.0)
>          #warning concat ("Invalid input argument ", str (X, 0, 4),
>   ". Argument must be positive. \n")
>          #break
>      #end
>
> But, seems like that needs to be an #error as your not handling Result
> on the #break. You could not do that check at all then below cheat
> around some potential divisions by zero by adding fudge factors but I
> have no immediate idea what this means for the validity of any result.

It was an #error, but I needed to force further parsing.
:)

>
> 4) The following line needs a semicolon:
>
> #local Test = Gamma (0.5)

I removed that after I set v to 3.1 because the parser complained about it being
there

>
> 5) In TestGamma() you have the line:
>
> #local computed = Gamma (test[T][0])

Same as above.

Thanks for looking - I prob won't be able to start tearing my hair out again
until late tonight or tomorrow.

- BW

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> and _then_ there's the first line:
> > #version 3.1;

I started with 3.8

edited

got pissed, and figured it was the lurking #local bug in macros,

set it to 3.7

then 3.5

then 3.1

which is when it started parsing differently / more thoroughly.

So that's how _that_ happened.


Hope you're doing well and staying cool,

BW

Post a reply to this message

> Also struggling a bit with
> result *= y++;
> I interpreted that as:
> #local Result = Result * (Y+1);
> (line 102)

The whole statement, when decomposed, can be interpreted in C/C++ as

      old_y = y ;
      y = y + 1 ;
      result = result * old_y ;

'y++' is interpreted as get the value of y, increment y by one then return the
value of y prior to incrementing it.

      #local Old_Y = Y ;
      #local Y = Y + 1 ;
      #local Result = Result * Old_Y ;

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

Post a reply to this message

"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