 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/25/24 11:53, jr wrote:
> our" as in not just 'yuqk' ? (because the wiki docs only mention 'float', and
> knowing it'll be a double is useful (I think))
I'm reasonably sure. :-)
It's true that the yuqk fork moved from the std::atof() function to
std::strtod() to enable better debugging on bad, but still sort of
getting converted strings. I wanted the debug compile of yuqk to return
detail on problems and not just continue onward with unintended values.
I believe both std::atof() and std::strtod() return doubles(*).
I'm not 100% sure what std::atof() might do on being passed "1.0f" say,
but it should be getting assign to a return double.
Suppose we have these two SDL lines where the first one is what we
intended and the second one is what we typed.
#debug concat("val(1.0123\") = ",str(val("1.0123"),19,17),"\n")
#debug concat("val(1.01 23\") = ",str(val("1.01 23"),19,17),"\n")
in v3.8 beta 2 or the non-debug compile of yuqk we get the following
output:
val(1.0123") = 1.01229999999999998 // (Example of str's noisy digits)
(f_boom() %g returns 1.0123 with default rounding)
val(1.01 23") = 1.01000000000000001 // Oops
Where the debug compile of yuqk returns:
val(1.0123") = 1.01229999999999998
File 'HUGE_VAL.pov' line 46:
Parse Error:
Error during val call At: < 23> converting <1.01 23>
Value set to <1.01>
---
And wonder of wonders, I used the same test scene file I was using for
the +-inf stuff and my debug compile dies on:
#debug concat("val(\"inf\") = ",str(val("+inf"),19,17),"\n")
but not in val but due an additional check I inserted in our expression
parsing... Ideally at that check I would remember be smart enough to
trust that std::strtod()'s own parsing handles the infinities correctly.
I'd bet there is no easy way to do that with 100% certainly and still
prevent other +-inf things which are very likely problems.
I'll look, but currently, I'd say now you cannot use infinities at all
in the debug version of yuqk. Thanks jr & BW for the questions.
Off to again update the new rulesOfThumbForMath.txt file - or the code,
if I can figure out how to let only infinite double returns from val()
past by the debug compile checking for infinite values.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/25/24 14:57, William F Pokorny wrote:
> Off to again update the new rulesOfThumbForMath.txt file - or the code,
> if I can figure out how to let only infinite double returns from val()
> past by the debug compile checking for infinite values.
The yuqk documentation was updated.
There isn't any practical way to turn off all the checking for
infinities in the debug compile of yuqk to allow for the setting of
+-inf via val().
So, in the non-debug compile of yuqk and all recent official POV-Ray
releases you can set +-inf values via val() and do things like
comparisons. However, the +-inf values are likely to cause undetected &
unreported problems should they make it into downstream math - or into
any down stream functions. Use with caution.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I got sidetracked onto something else so I didn't try any of this out (yet).
What I did do is snare myself into the whole pass-by-reference trap when trying
to run a macro in a loop.
https://news.povray.org/povray.advanced-users/message/%3C63dd9c26%241%40news.povray.org%3E/#%3C63dd9c26%241%40news.povr
ay.org%3E
This is very sneaky, and even though I'm aware of this problem, it still didn't
register when I was trying to debug my code, and it only dawned on me this
morning that this is what was happening.
I went through all of my code and was trying to find why my loop counter wasn't
incrementing, and I was stuck in an infinite loop. My debug statement
overloaded the text stream, and I had to manually terminate the POV-Ray process
and restart nearly a dozen times before I fixed the problem.
Perhaps consider issuing a warning that an identifier is being passed by
reference, or some other mechanism to help fix, or better - avoid this problem
in the first place.
(Does anyone have any protective "wrapper" code to somehow alert that an
identifier is being passed into a macro that can be modified by the macro rather
than dummy/placeholder identifier?)
I also unconsciously engage in the bad habit of running loops from 0 to 1,
creating fractional loop counter values. "Fractional loop counter value"
warning would be useful just to stay out of the weeds in some of the hairier
code.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Works pretty nice! :)
Any way to force str to prepend the + sign to +inf?
val ("+inf") = inf
val ("-inf") = -inf
val ("+nan") = nan
val ("-nan") = -nan
val (1.0123") = 1.01229999999999998
val (1.01 23") = 1.01000000000000001
val ("inf") = inf
=============================================
Val1 = -1.00000000
Val2 = 1.00000000
Val1 < Val2
Val1 = -1.00000000
Val2 = 0.00000000
Val1 < Val2
Val1 = -1.00000000
Val2 = -1.00000000
Val1 = Val2
Val1 = 0.00000000
Val2 = 0.00000000
Val1 = Val2
Val1 = 1.00000000
Val2 = 1.00000000
Val1 = Val2
Val1 = -inf
Val2 = inf
Val1 < Val2
Val1 = inf
Val2 = inf
Val1 = Val2
Val1 = -inf
Val2 = inf
Val1 < Val2
Val1 = inf
Val2 = inf
Val1 = Val2
Val1 = nan
Val2 = inf
Val1 = Val2
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/26/24 19:29, Bald Eagle wrote:
> Any way to force str to prepend the + sign to +inf?
Not presently. :-)
I'm sure it's possible to modify the internal str() code to do it, but...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/26/24 19:29, Bald Eagle wrote:
> > Any way to force str to prepend the + sign to +inf?
>
> Not presently. :-)
>
> I'm sure it's possible to modify the internal str() code to do it, but...
>
> Bill P.
Macro it is.
(I guess we don't have anything like numeric formatting (#.###.###) . . . yet.)
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Works pretty nice! :)
>
> Any way to force str to prepend the + sign to +inf?
>
> val ("+inf") = inf
> val ("-inf") = -inf
> val ("+nan") = nan
> val ("-nan") = -nan
> val (1.0123") = 1.01229999999999998
> val (1.01 23") = 1.01000000000000001
> val ("inf") = inf
> =============================================
> Val1 = -1.00000000
> Val2 = 1.00000000
> Val1 < Val2
>
> Val1 = -1.00000000
> Val2 = 0.00000000
> Val1 < Val2
>
> Val1 = -1.00000000
> Val2 = -1.00000000
> Val1 = Val2
>
> Val1 = 0.00000000
> Val2 = 0.00000000
> Val1 = Val2
>
> Val1 = 1.00000000
> Val2 = 1.00000000
> Val1 = Val2
>
> Val1 = -inf
> Val2 = inf
> Val1 < Val2
>
> Val1 = inf
> Val2 = inf
> Val1 = Val2
>
> Val1 = -inf
> Val2 = inf
> Val1 < Val2 <--- Oooh, nice.
>
> Val1 = inf
> Val2 = inf
> Val1 = Val2
>
> Val1 = nan
> Val2 = inf <--- possibly good, possibly bad.
> Val1 = Val2
If anyone's up for writing some SDL, (I'm stuck here for the next 5h)
I need reliable ways to detect +/- inf and +/- nan.
In the #if MyVal = val("inf") sort of way.
^^^
That doesn't need to be the exact implementation, I just need the equivalent
that yields the correct Boolean result.
Square it, multiply it by zero, by -1, test equality to itself, subtract it from
itself, add it to itself, abs(), .... whatever works to
_differentiate inf and nan from the real numbers_.
Thanks!
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
