polybori: new boost version gives different random values

36 views
Skip to first unread message

Timo Kluck

unread,
Feb 27, 2013, 12:39:39 PM2/27/13
to sage-...@googlegroups.com
Hi there,

I'm looking for someone who's familiar with Polybori to have a quick look at the following ticket:
http://trac.sagemath.org/sage_trac/ticket/13767

The issue is that we're upgrading boost, and apparently, its random number generator has slightly changed. Therefore, we have some failing doctests for random_set.

I'm guessing this is a non-issue and we can just update the doctests, but could someone who actually knows something about polybori confirm that? Thanks!

Best regards, Timo

Nils Bruin

unread,
Feb 27, 2013, 1:57:59 PM2/27/13
to sage-devel
On Feb 27, 9:39 am, Timo Kluck <tkl...@gmail.com> wrote:
> The issue is that we're upgrading boost, and apparently, its random number
> generator has slightly changed. Therefore, we have some failing doctests
> for random_set.

Do we really want to test our random number generators for
deterministic behaviour? If so, the test should probably at least set
the seed prior to testing things that depend on actual values
produced. Of course, if the algorithm used for the pseudo-random
generator has actually changed, setting the seed would not be enough,
but that should be rare.

The more appropriate thing might be to rewrite the test to check
general behaviour rather than rely on exact output.

Simon King

unread,
Feb 27, 2013, 2:19:32 PM2/27/13
to sage-...@googlegroups.com
Hi Nils,

On 2013-02-27, Nils Bruin <nbr...@sfu.ca> wrote:
> On Feb 27, 9:39 am, Timo Kluck <tkl...@gmail.com> wrote:
>> The issue is that we're upgrading boost, and apparently, its random number
>> generator has slightly changed. Therefore, we have some failing doctests
>> for random_set.
>
> Do we really want to test our random number generators for
> deterministic behaviour? If so, the test should probably at least set
> the seed prior to testing things that depend on actual values
> produced.

Isn't this the case already? In doctests, one can assume that the output
of our random number generators is deterministic.

> Of course, if the algorithm used for the pseudo-random
> generator has actually changed, setting the seed would not be enough,
> but that should be rare.

If I understand correctly, that rare situation occurs here. Hence, one can
still rely on deterministic output, but a *different* deterministic output.

> The more appropriate thing might be to rewrite the test to check
> general behaviour rather than rely on exact output.

+1

Testing against theorems (such as: One has random data, but the test is
using an identity that must hold for any data) is most elegant.

Cheers,
SImon


Timo Kluck

unread,
Feb 27, 2013, 6:19:34 PM2/27/13
to sage-...@googlegroups.com
Op woensdag 27 februari 2013 20:19:32 UTC+1 schreef Simon King het volgende:
Hi Nils,

On 2013-02-27, Nils Bruin <nbr...@sfu.ca> wrote:

> Do we really want to test our random number generators for
> deterministic behaviour? If so, the test should probably at least set
> the seed prior to testing things that depend on actual values
> produced.

Isn't this the case already?
In this case, it is. The random number seed is even explicitly set (to 1337) in the doctest itself.
 

> Of course, if the algorithm used for the pseudo-random
> generator has actually changed, setting the seed would not be enough,
> but that should be rare.

If I understand correctly, that rare situation occurs here. Hence, one can
still rely on deterministic output, but a *different* deterministic output.
Exactly.
 

> The more appropriate thing might be to rewrite the test to check
> general behaviour rather than rely on exact output.

+1

Testing against theorems (such as: One has random data, but the test is
using an identity that must hold for any data) is most elegant.

I agree. I don't know much about polybori though, so I can't really change those doctests in that way.

My question is mostly: I assess the situation as being such as you describe above: there is a rare situation where we should accept finding different, yet deterministic, output. However, maybe a polybori expert might correct me and say that this random_set function is often used in such a way that it is vital that it stays backward compatible. I have a hard time imagining that, but I'd better be safe than sorry.

It would be great if someone who actually knows what anyone would want to use random_set for, to give us the go-ahead.

Best, Timo

François Bissey

unread,
Feb 27, 2013, 6:36:45 PM2/27/13
to sage-...@googlegroups.com
Actually because in sage-on-gentoo we use the system boost we hit that
particular doctest failure a long time ago. I then asked Alexander Dreyer who
works on polybori if the output was ok and it didn't seem to be concerned.

You can give him a ping for his opinion. Martin Albretch could also be
contacted.

Francois

Alexander Dreyer

unread,
Feb 28, 2013, 3:37:37 AM2/28/13
to sage-...@googlegroups.com
Hi everybody!

Actually because in sage-on-gentoo we use the system boost we hit that
particular doctest failure a long time ago. I then asked Alexander Dreyer who
works on polybori if the output was ok and it didn't seem to be concerned.
Indeed, you can safely ignore the changes in the random output, since these are just user functions for generating random elements.
But maybe one could test for the following assumed properties:
  result =  random_set(monomial, n)
should obey
  len(result) == 1
and
  result.diff(monomial.divisors()).empty()

Best regards,
  Alexander
Reply all
Reply to author
Forward
0 new messages