The compiler is too functional that it considers any two random integer elements in `[m .. n]` as equal :smile:

[kamalsaleh]

Two elements

a := Random( [ 1 .. 10 ] );
b := Random( [ 1 .. 10 ] );

turn into one hoisted variable. Hence, 'random morphisms' in k-mat are all endomorphisms :-)

Reason: the following derivation

https://github.com/homalg-project/CAP_project/blob/74467a1fcfdec82178bdc0985de96f528a76fe29/CAP/gap/DerivedMethods.gi#L1464-L1477

compiles to

https://github.com/homalg-project/CAP_project/blob/74467a1fcfdec82178bdc0985de96f528a76fe29/LinearAlgebraForCAP/gap/precompiled_categories/MatrixCategoryPrecompiled.gi#L4672-L4685

where the RandomObjectByInteger is implemented as follows:

https://github.com/homalg-project/CAP_project/blob/74467a1fcfdec82178bdc0985de96f528a76fe29/LinearAlgebraForCAP/gap/precompiled_categories/MatrixCategoryPrecompiled.gi#L4736-L4743

[zickgraf]

Haskell has two solutions for this problem:

1. The "pure" versions of random functions all explicitly get and return a state, which is then used as input for the next random function.
2. This can also be done implicitly by using monads.

Both solutions are not really feasibly in our context right now. The easiest solution would be to simply don't dedupe expressions in Random.... A more elaborate solutions would be to to keep a list of functions returning random things and don't deduplicate any expressions containing such functions.

[zickgraf]

I just noticed that things are even worse: not deduping will in general give wrong results, e.g. in the following situation:

CategoryOfRowsMorphism( CategoryOfRowsObject( cat, Random( ... ) ), RandomMatrix( ... ),  CategoryOfRowsObject( cat, Random( ... ) ) );

I.e., already the inlining step is wrong for random functions -> I will simply exclude them from compilation for now.

[zickgraf]

I have excluded random methods from the compilation in aab7cbd3efa8c885e0a11d47ed2028378f3cc45a. I will keep this issue open for future reference.

[kamalsaleh]

Thank you for the quick workaround. Of course, not compiling them is better than having not-well-defined outputs.

Also, for future reference, the above implies that because MatrixCategory(k) is purely compiled code, the random-methods are not added. Random methods, however, are still available in MatrixCategoryAsCategoryOfRows(k).