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