random from IntegerNumberSystem

[oldk1331]

The document says:
random : % -> %
++ random(n) creates a random element from 0 to \spad{n-1}.

That is good if n is positive. What if n is negative?

(2) -> random(-5)

>> System error:
Argument is neither a positive integer nor a positive float: -5

Also this definition can't cover the case when n is 0.

I suggest to change the documentation and implementation to
return a random element from 0 to n.

[Waldek Hebisch]

>
> The document says:
> random : % -> %
> ++ random(n) creates a random element from 0 to \spad{n-1}.
>
> That is good if n is positive. What if n is negative?

When n is 0 or negative then segment 0..(n - 1) is empty, so
call is incorrect.

> (2) -> random(-5)
>
> >> System error:
> Argument is neither a positive integer nor a positive float: -5

And you get error, as expected.

> Also this definition can't cover the case when n is 0.
>
> I suggest to change the documentation and implementation to
> return a random element from 0 to n.

Current definition means that for positive n you get exactly n
values, each with probablility 1/n. Your proposed change would
break this nice relationship. For people who can not read
between lines we could add phrase: 'Error if n <= 0.'.

--
Waldek Hebisch

[oldk1331]

> Current definition means that for positive n you get exactly n
> values, each with probablility 1/n. Your proposed change would
> break this nice relationship. For people who can not read
> between lines we could add phrase: 'Error if n <= 0.'.

Then the signature for random will be awkward: PI -> NNI

For my definition, it's valid for all integers (if n<0, return random
integer from -n to 0), although the probablility will be 1/(n+1).

[Kurt Pagani]

PI->NNI ? Awkward indeed.

In other langs:
C++
int rand (void);
Returns a pseudo-random integral number in the range between 0 and RAND_MAX.

Python

import random
print(random.randint(-9,9))

PHP
int rand ( int $min , int $max )

CL (where Fricas' random is based on)
http://clhs.lisp.se/Body/f_random.htm
This might explain why 'random' it's implemented as is.
What about the quality of RANDOM()$Lisp?

(1) -> )d op random

There are 6 exposed functions called random :
   [1]  -> D from D if D has FINITE
   [2] D -> D from D if D has INS
   [3] Integer -> Integer from Integer
   [4] NonNegativeInteger -> NonNegativeInteger from NonNegativeInteger

   [5] PermutationGroup(D2) -> Permutation(D2) from PermutationGroup(D2
            )
            if D2 has SETCAT
   [6] (PermutationGroup(D3),Integer) -> Permutation(D3)
            from PermutationGroup(D3) if D3 has SETCAT

There are 3 unexposed functions called random :
   [1] PositiveInteger -> SparseUnivariatePolynomial(D3)
            from FiniteFieldPolynomialPackage(D3) if D3 has FFIELDC
   [2] (PositiveInteger,PositiveInteger) -> SparseUnivariatePolynomial(
            D3)
            from FiniteFieldPolynomialPackage(D3) if D3 has FFIELDC
   [3] PositiveInteger -> Vector(D3) from
            InnerNormalBasisFieldFunctions(D3)
            if D3 has FFIELDC


Yet

(2) -> random(-4::Integer)$Integer

   >> System error:
   Argument is neither a positive integer nor a positive float: -4

[Kurt Pagani]

CL (where Fricas' random is based on)
http://clhs.lisp.se/Body/f_random.htm
This might explain why 'random' it's implemented as is.
What about the quality of RANDOM()$Lisp?

The following page is about Lisp's RANDOM function (apparently a Mersenne Twister).
The comments therein (at the end) might also be of interest.
https://jorgetavares.com/2009/09/02/exploring-pseudo-random-numbers-in-lisp/

Function 'random' is found in several .spad files and cannot be changed easily (see below, e.g. permgrps).
Perhaps a new function random: (INT,INT) -> INT or Interval(INT) -> INT could be created?
Preferably considering make-random-state. A linear transformation on RANDOM then should do.

---

integer.spad
si.spad
random(x) == RANDOM(x)$Lisp

random.spad (unused?)

catdef.spad
random() == index((1+random(size()$%))::PositiveInteger)

permgrps.spad
randomInteger : I := 1 + random(numberOfGenerators)$Integer

and a lot more ...

[Waldek Hebisch]

Kurt Pagani wrote:
>
> Function 'random' is found in several .spad files and cannot be changed
> easily (see below, e.g. permgrps).
> Perhaps a new function random: (INT,INT) -> INT or Interval(INT) -> INT
> could be created?

For finite domains 'random' is defined to play reasonably with
other FriCAS routines. In particular, user is supposed to use
'random' from given domain and implementer can use 'random'
from Integer to implement random for given domain. So I see
little need for extra variants: users in most cases are
supposed to work at higher level and for implementers of
library functions current version is enough.

Actually, what is needed is higher level version of 'random(n)'
for other infinite domains. I wrote some time ago about
RandomChoice, that was a proposal for such functionalty.
ATM I am not decided about it, it solves some problems
but some other remain.

--
Waldek Hebisch

[Kurt Pagani]

Am 23.10.2016 um 07:15 schrieb Waldek Hebisch:
> Kurt Pagani wrote:
>>
>> Function 'random' is found in several .spad files and cannot be changed
>> easily (see below, e.g. permgrps).
>> Perhaps a new function random: (INT,INT) -> INT or Interval(INT) -> INT
>> could be created?
>
> For finite domains 'random' is defined to play reasonably with
> other FriCAS routines. In particular, user is supposed to use
> 'random' from given domain and implementer can use 'random'
> from Integer to implement random for given domain. So I see
> little need for extra variants: users in most cases are
> supposed to work at higher level and for implementers of
> library functions current version is enough.

Regarding the last statement I'm not so sure. Considering that 'random' merely
being RANDOM()$Lisp wihout the possibility to create/save random states its use
is certainly limited. OTOH I agree that everyone knowing about RANDOM ought to
be able to write his own 'random'. At least the signature/docstring should be
adjusted (PI->NNI, not nice but according to CLHS).

>