[FFmpeg-devel] [PATCH 1/2] libavutil/eval: introduce UINT64_MAX constant

[FFmpeg-devel] [PATCH 1/2] libavutil/eval: introduce UINT64_MAX constant

[Stefano Sabatini]

This might be useful, e.g. when setting the random seed expressed as a
uint64_t.
---
 doc/utils.texi   | 3 +++
 libavutil/eval.c | 1 +
 2 files changed, 4 insertions(+)

diff --git a/doc/utils.texi b/doc/utils.texi
index 0c4f146f4f..ac9b63826e 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -1030,6 +1030,9 @@ area of the unit disc, approximately 3.14
 exp(1) (Euler's number), approximately 2.718
 @item PHI
 golden ratio (1+sqrt(5))/2, approximately 1.618
+@item UINT64_MAX
+maximum value expressed as an unsigned integer, corresponds to
+18446744073709551616 ((2^64)-1)
 @end table
 
 Assuming that an expression is considered "true" if it has a non-zero
diff --git a/libavutil/eval.c b/libavutil/eval.c
index dc6b3697bc..93048bff91 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -100,6 +100,7 @@ static const struct {
     { "PI",  M_PI  },
     { "PHI", M_PHI },
     { "QP2LAMBDA", FF_QP2LAMBDA },
+    { "UINT64_MAX", UINT64_MAX }
 };
 
 double av_strtod(const char *numstr, char **tail)
-- 
2.34.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] doc/utils/eval: clarify meaning of random* seed value

[Stefano Sabatini]

Possible address trac issue:
http://trac.ffmpeg.org/ticket/10763
---
 doc/utils.texi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/utils.texi b/doc/utils.texi
index ac9b63826e..554a07f057 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -944,11 +944,17 @@ Return a pseudo random value between 0.0 and 1.0. @var{idx} is the
 index of the internal variable which will be used to save the
 seed/state.
 
+The seed is represented as 64-bit unsigned integer. You can use a
+fraction of @code{UINT64_MAX} to initialize it.
+
 @item randomi(idx, min, max)
 Return a pseudo random value in the interval between @var{min} and
 @var{max}. @var{idx} is the index of the internal variable which will
 be used to save the seed/state.
 
+The seed is represented as 64-bit unsigned integer. You can use a
+fraction of @code{UINT64_MAX} to initialize it.
+
 @item root(expr, max)
 Find an input value for which the function represented by @var{expr}
 with argument @var{ld(0)} is 0 in the interval 0..@var{max}.
-- 
2.34.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] libavutil/eval: introduce UINT64_MAX constant

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1150 bytes --]

On Mon, Jan 01, 2024 at 08:38:58PM +0100, Stefano Sabatini wrote:
> This might be useful, e.g. when setting the random seed expressed as a
> uint64_t.
> ---
>  doc/utils.texi   | 3 +++
>  libavutil/eval.c | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/doc/utils.texi b/doc/utils.texi
> index 0c4f146f4f..ac9b63826e 100644
> --- a/doc/utils.texi
> +++ b/doc/utils.texi
> @@ -1030,6 +1030,9 @@ area of the unit disc, approximately 3.14
>  exp(1) (Euler's number), approximately 2.718
>  @item PHI
>  golden ratio (1+sqrt(5))/2, approximately 1.618
> +@item UINT64_MAX
> +maximum value expressed as an unsigned integer, corresponds to

> +18446744073709551616 ((2^64)-1)

this doesnt look right
2^x is even
even -1 is odd
18446744073709551616 should be a odd number
18446744073709551615 looks more likely

double precission also doesnt like exactly ((2^64)-1) because the mantisse has too few bits

(U)INT64_MIN should work though exactly in double

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] doc/utils/eval: clarify meaning of random* seed value

[Michael Koch]

 > Possible address trac issue:

> http://trac.ffmpeg.org/ticket/10763

I don't like the random generator as it is, because the first two random numbers
are very close to zero, as can be shown with this command line:
ffmpeg -loglevel repeat -f lavfi -i nullsrc=size=1x1,format=gray -vf 
"geq=lum='print(random(0));print(random(0));print(random(0));print(random(0))'" 
-frames 1 -y out.png 0.000000 0.000091 0.285346 0.929202 This behaviour 
can be improved by inizializing the generator with a large number as 
seed value. I'm not sure if it's a good idea to share the same variables 
for ld() and st() (as double) and random() (as unsigned int). Wouldn't 
it be better to use separate variables for random()? Michael

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] doc/utils/eval: clarify meaning of random* seed value

[Stefano Sabatini]

On date Wednesday 2024-01-03 12:20:12 +0100, Michael Koch wrote:
> > Possible address trac issue:
> 
> > http://trac.ffmpeg.org/ticket/10763
> 

> I don't like the random generator as it is, because the first two random numbers
> are very close to zero, as can be shown with this command line:
> ffmpeg -loglevel repeat -f lavfi -i nullsrc=size=1x1,format=gray -vf "geq=lum='print(random(0));print(random(0));print(random(0));print(random(0))'"
> -frames 1 -y out.png 0.000000 0.000091 0.285346 0.929202 This behaviour can
> be improved by inizializing the generator with a large number as seed value.

OTOH this seems only to happen with 0, which is also the default seed
value used by the random generator (since all variables are set to 0).

$ echo "st(0, UINT64_MAX/3); st(1, 10); while(gt(ld(1), 0), print(random(0)); st(1, ld(1)-1))" | tools/ffeval 
0.666667
0.333374
0.616496
0.023515
0.931519
0.317050
0.393449
0.969531
0.842403
0.129183
=> 0.000000
$ echo "st(0, UINT64_MAX/2); st(1, 10); while(gt(ld(1), 0), print(random(0)); st(1, ld(1)-1))" | tools/ffeval 
0.500000
0.500091
0.785217
0.673490
0.103073
0.829142
0.144794
0.508226
0.735092
0.655693
=> 0.000000
$ echo "st(0, UINT64_MAX/7); st(1, 10); while(gt(ld(1), 0), print(random(0)); st(1, ld(1)-1))" | tools/ffeval 
0.285714
0.571498
0.855853
0.398648
0.009648
0.802972
0.608529
0.007854
0.405221
0.959683
=> 0.000000
$ echo "st(0, UINT64_MAX/13); st(1, 10); while(gt(ld(1), 0), print(random(0)); st(1, ld(1)-1))" | tools/ffeval 
0.384615
0.923180
0.593572
0.754748
0.415309
0.067556
0.905708
0.928599
0.448587
0.772728
=> 0.000000
$ echo "st(0, UINT64_MAX/6); st(1, 10); while(gt(ld(1), 0), print(random(0)); st(1, ld(1)-1))" | tools/ffeval 
0.833333
0.166733
0.451010
0.605203
0.240940
0.007228
0.778975
0.354595
0.413333
0.898240
=> 0.000000
$ echo "st(0, 0); st(1, 10); while(gt(ld(1), 0), print(random(0)); st(1, ld(1)-1))" | tools/ffeval 
0.000000
0.000091
0.285346
0.929202
0.239519
0.140744
0.686872
0.275489
0.537404
0.583466
=> 0.000000

(BTW it could be handy to have an inc and dec function as well to
simplify this kind of loops.)

> I'm not sure if it's a good idea to share the same variables for ld() and
> st() (as double) and random() (as unsigned int).

All functions work with double precision floating point numbers, but
they can be used also to represent integers, but with a few
limitations (e.g. you cannot represent many integers with a float
exactly).

> Wouldn't it be better to use separate variables for random()?
> Michael

One idea would be to use a random_seed(idx) function, but this would mean
that we need to use separate registers only for the random function,
and this would also break backward compatibility.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] libavutil/eval: introduce UINT64_MAX constant

[Stefano Sabatini]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On date Tuesday 2024-01-02 01:10:28 +0100, Michael Niedermayer wrote:
> On Mon, Jan 01, 2024 at 08:38:58PM +0100, Stefano Sabatini wrote:
> > This might be useful, e.g. when setting the random seed expressed as a
> > uint64_t.
> > ---
> >  doc/utils.texi   | 3 +++
> >  libavutil/eval.c | 1 +
> >  2 files changed, 4 insertions(+)
> > 
> > diff --git a/doc/utils.texi b/doc/utils.texi
> > index 0c4f146f4f..ac9b63826e 100644
> > --- a/doc/utils.texi
> > +++ b/doc/utils.texi
> > @@ -1030,6 +1030,9 @@ area of the unit disc, approximately 3.14
> >  exp(1) (Euler's number), approximately 2.718
> >  @item PHI
> >  golden ratio (1+sqrt(5))/2, approximately 1.618
> > +@item UINT64_MAX
> > +maximum value expressed as an unsigned integer, corresponds to
> 
> > +18446744073709551616 ((2^64)-1)
> 
> this doesnt look right
> 2^x is even
> even -1 is odd
> 18446744073709551616 should be a odd number
> 18446744073709551615 looks more likely
> 
> double precission also doesnt like exactly ((2^64)-1) because the mantisse has too few bits
> 
> (U)INT64_MIN should work though exactly in double

Updated.

[-- Attachment #2: 0001-libavutil-eval-introduce-UINT64_MAX-constant.patch --]
[-- Type: text/x-diff, Size: 1255 bytes --]

From f2772a82779b16982e3bc74176c6ff1011156096 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini <stefasab@gmail.com>
Date: Mon, 1 Jan 2024 20:32:38 +0100
Subject: [PATCH 1/2] libavutil/eval: introduce UINT64_MAX constant

This might be useful, e.g. when setting the random seed expressed as a
uint64_t value.
---
 doc/utils.texi   | 3 +++
 libavutil/eval.c | 1 +
 2 files changed, 4 insertions(+)

diff --git a/doc/utils.texi b/doc/utils.texi
index 0c4f146f4f..dec009a015 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -1030,6 +1030,9 @@ area of the unit disc, approximately 3.14
 exp(1) (Euler's number), approximately 2.718
 @item PHI
 golden ratio (1+sqrt(5))/2, approximately 1.618
+@item UINT64_MAX
+maximum value expressed as an unsigned 64-bits integer, corresponds to
+18446744073709551615 ((2^64)-1)
 @end table
 
 Assuming that an expression is considered "true" if it has a non-zero
diff --git a/libavutil/eval.c b/libavutil/eval.c
index dc6b3697bc..93048bff91 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -100,6 +100,7 @@ static const struct {
     { "PI",  M_PI  },
     { "PHI", M_PHI },
     { "QP2LAMBDA", FF_QP2LAMBDA },
+    { "UINT64_MAX", UINT64_MAX }
 };
 
 double av_strtod(const char *numstr, char **tail)
-- 
2.34.1


[-- Attachment #3: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] doc/utils/eval: clarify meaning of random* seed value

[Michael Koch]

On one hand, it's good that the 10 variables for ld() and st() are 
initialized with zero.
But on the other hand, zero is obviously the worst possible seed value 
for the random generator.

For example, make a 1000x1000 image with red color, and then fill one 
pixel at a random position with yellow color. Surprise surprise, the 
pixel is in the top left corner. That's not what a user expects from a 
random generator. It took me some time to figure out what's the problem, 
and how to set a better seed value.

Michael

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] doc/utils/eval: clarify meaning of random* seed value

[Michael Koch]

Possible better algorithm for the random generator, which might fix the 
problem:

eval.c  line 235

if (r == 0)
   r = UINT64_MAX/13;
else
   r = r*1664525+1013904223;

Michael
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] libavutil/eval: introduce UINT64_MAX constant

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3001 bytes --]

On Wed, Jan 03, 2024 at 05:17:07PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2024-01-02 01:10:28 +0100, Michael Niedermayer wrote:
> > On Mon, Jan 01, 2024 at 08:38:58PM +0100, Stefano Sabatini wrote:
> > > This might be useful, e.g. when setting the random seed expressed as a
> > > uint64_t.
> > > ---
> > >  doc/utils.texi   | 3 +++
> > >  libavutil/eval.c | 1 +
> > >  2 files changed, 4 insertions(+)
> > > 
> > > diff --git a/doc/utils.texi b/doc/utils.texi
> > > index 0c4f146f4f..ac9b63826e 100644
> > > --- a/doc/utils.texi
> > > +++ b/doc/utils.texi
> > > @@ -1030,6 +1030,9 @@ area of the unit disc, approximately 3.14
> > >  exp(1) (Euler's number), approximately 2.718
> > >  @item PHI
> > >  golden ratio (1+sqrt(5))/2, approximately 1.618
> > > +@item UINT64_MAX
> > > +maximum value expressed as an unsigned integer, corresponds to
> > 
> > > +18446744073709551616 ((2^64)-1)
> > 
> > this doesnt look right
> > 2^x is even
> > even -1 is odd
> > 18446744073709551616 should be a odd number
> > 18446744073709551615 looks more likely
> > 
> > double precission also doesnt like exactly ((2^64)-1) because the mantisse has too few bits
> > 
> > (U)INT64_MIN should work though exactly in double
> 
> Updated.

>  doc/utils.texi   |    3 +++
>  libavutil/eval.c |    1 +
>  2 files changed, 4 insertions(+)
> 97bdb4309465dc8ad995abb2740d3f3063251398  0001-libavutil-eval-introduce-UINT64_MAX-constant.patch
> From f2772a82779b16982e3bc74176c6ff1011156096 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini <stefasab@gmail.com>
> Date: Mon, 1 Jan 2024 20:32:38 +0100
> Subject: [PATCH 1/2] libavutil/eval: introduce UINT64_MAX constant
> 
> This might be useful, e.g. when setting the random seed expressed as a
> uint64_t value.
> ---
>  doc/utils.texi   | 3 +++
>  libavutil/eval.c | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/doc/utils.texi b/doc/utils.texi
> index 0c4f146f4f..dec009a015 100644
> --- a/doc/utils.texi
> +++ b/doc/utils.texi
> @@ -1030,6 +1030,9 @@ area of the unit disc, approximately 3.14
>  exp(1) (Euler's number), approximately 2.718
>  @item PHI
>  golden ratio (1+sqrt(5))/2, approximately 1.618
> +@item UINT64_MAX
> +maximum value expressed as an unsigned 64-bits integer, corresponds to
> +18446744073709551615 ((2^64)-1)
>  @end table

This has unexpected issues

because its in double based table
18446744073709551615 cant be stored in a double so it will become 18446744073709551616
the difference is very small but the value is not the maximum representable but
rather the smallest non representable integer and also the smallest non representable double

so really its
2^64
POW2_64

given that, POW2_64 seems the more precisse name. And how much faster is that
than 2^64 ?

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] doc/utils/eval: clarify meaning of random* seed value

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 656 bytes --]

On Wed, Jan 03, 2024 at 07:36:00PM +0100, Michael Koch wrote:
> Possible better algorithm for the random generator, which might fix the
> problem:
> 
> eval.c  line 235
> 
> if (r == 0)
>   r = UINT64_MAX/13;
> else
>   r = r*1664525+1013904223;

This modifies the properties of the PRNG as it doesnt just change
the seed but jumps the generator from 0 to a differnt value, that
may happen more often than just at the start

posted a more correct fix for the low quality numbers

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".