I have written this macro to generate integers in [0..A[

 #macro RandInt(A, RS)  floor(A * rand(RS) * 0.999999)  #end

The factor 0.999999 is to ensure A itself is excluded; rand() returns a value in
[0..1], so including 1.

When I use #debug to see the macro's return value it's fine, but when I assign
it to a variable, like

 #declare somevar = RandInt(4, Rnd3);

somevar will always be 0. Can anybody explain this, and how to solve it? I've
written several similar macros which work fine.

TIA
Steven

Post a reply to this message

Am 25.05.2017 um 15:03 schrieb stevenvh:
> I have written this macro to generate integers in [0..A[
> 
>  #macro RandInt(A, RS)  floor(A * rand(RS) * 0.999999)  #end
> 
> The factor 0.999999 is to ensure A itself is excluded; rand() returns a value in
> [0..1], so including 1.
> 
> When I use #debug to see the macro's return value it's fine, but when I assign
> it to a variable, like
> 
>  #declare somevar = RandInt(4, Rnd3);
> 
> somevar will always be 0. Can anybody explain this, and how to solve it? I've
> written several similar macros which work fine.

Looks to me like your problem is somewhere else. Maybe a minimal
self-contained scene file demonstrating the problem would help.

Post a reply to this message

"stevenvh" <nomail@nomail> wrote:
> I have written this macro to generate integers in [0..A[
>
>  #macro RandInt(A, RS)  floor(A * rand(RS) * 0.999999)  #end
>
> The factor 0.999999 is to ensure A itself is excluded; rand() returns a value in
> [0..1], so including 1.
>
> When I use #debug to see the macro's return value it's fine, but when I assign
> it to a variable, like
>
>  #declare somevar = RandInt(4, Rnd3);
>
> somevar will always be 0. Can anybody explain this, and how to solve it? I've
> written several similar macros which work fine.
>
> TIA
> Steven

I suspect that the problem comes from not reseeding Rand(...) Every time the
macro is called. I'M ve run into this problem myself.

These days, I always use Rand_Normal(...) From rand.inc

Regards,
A.D.B.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Looks to me like your problem is somewhere else. Maybe a minimal
> self-contained scene file demonstrating the problem would help.

OK, so I stripped everything unnecessary for creating some output and saved it
as test.pov. What do you think? It works, of course :-(.
I then removed code line by line from my original file until it would work. By
the way, "work" means it doesn't go in an infinite parsing loop.
The code contains

#declare colorRnd1 = 0;
#declare colorRnd2 = 0;
#while ( colorRnd2 = colorRnd1 )
  #declare colorRnd1 = RandInt(4, Rnd3);
  #declare colorRnd2 = RandInt(4, Rnd3);
#end

and since RandInt always seems to return zero it never exits the while loop.

In the end I had a file which still didn't work and an identical-looking one
which did work. Since the problem seemed to be with the RandInt I scrutinized
the above lines. I compared them character by character (esp. the digits!). And
did so 5 (five) times. They were identical in both files.
If there was any difference it was not visible as ASCII text. So I copied the
above code from the working test.pov and pasted it in the other file.
Result: the latter also works.

I regret that I didn't compare the files with a hex editor. I believe there was
one or more erroneous characters in the file which confused the parser.
This happened to me before! A file which looked syntactically and semantically
OK caused parsing errors. After spending an eternity checking the syntax I
finally put the cursor some 40 or 50 characters after what should have been the
end of the line, and backspaced until the last non-blank character. Problem
solved.

I'm using the POVray for Windows editor component; possibly the cause of the
problem lies there. (I'm not very fond of PovClipse. Eclipse is written in Java,
and Java is infamous for being a huge security liability.)

Post a reply to this message

Where are you defining the value for Rnd3 ?

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Where are you defining the value for Rnd3 ?

In my OP I said that #debug showed that non-zero values were generated, so that
wasn't the problem.

In my previous post I explained that the .pov file's text seemed to have been
corrupted with non-visible characters.

Thanks for your time, though.

Post a reply to this message

Am 25.05.2017 um 17:17 schrieb Anthony D. Baye:

> I suspect that the problem comes from not reseeding Rand(...) Every time the
> macro is called. I'M ve run into this problem myself.

Uh... the general recommended practice is to *NOT* reseed. Otherwise you
*WILL* get the same result each time you call the macro.

Post a reply to this message

> In my previous post I explained that the .pov file's text seemed to have been
> corrupted with non-visible characters.
>
> Thanks for your time, though.

It would still be worth posting the scene file that *doesn't* work (as 
attachments rather than copy&paste), just so others can see what's going 
on and how to avoid in future. I've never had this problem before, how 
do you think you got the strange characters in there? Were you entering 
special characters or copying&pasting from another source?

Post a reply to this message

just came across this, so someone has noticed the same type of problem (though
not in povray)


http://abel.math.harvard.edu/~knill/technology/index.html


23-10-2015: While Mimic is funny, there is a serious side. I use demononizer
since more than a decade (practically in any script which processes content from
a website) as Microsoft has in their "time of evil" completely ruined things. We
have got used to it, but it still happens to me regularly that a string
formatted of Microsoft (or Adobe) origin (especially " or - symbols) ruined a
program from running. There is nothing more frustrating than to have two texts
which look identical in the editor, where one works, the other not and where
only watching the file with a binhex editor reveals the hidden difference.

Post a reply to this message