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

[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

CAP_project/CAP/gap/DerivedMethods.gi

Lines 1464 to 1477 in 74467a1

	##
	AddDerivationToCAP( RandomMorphismByInteger,
	[
	[ RandomObjectByInteger, 2 ],
	[ RandomMorphismWithFixedSourceAndRangeByInteger, 1 ]
	],
	function( cat, n )
	return RandomMorphismWithFixedSourceAndRangeByInteger( cat, RandomObjectByInteger( cat, n ), RandomObjectByInteger( cat, n ), n );
	end : CategoryFilter := IsAbCategory,
	Description := "RandomMorphismByInteger using RandomObjectByInteger and RandomMorphismWithFixedSourceAndRangeByInteger" );

compiles to

CAP_project/LinearAlgebraForCAP/gap/precompiled_categories/MatrixCategoryPrecompiled.gi

Lines 4672 to 4685 in 74467a1

	##
	AddRandomMorphismByInteger( cat,
	########
	function ( cat_1, n_1 )
	local morphism_attr_1_1, hoisted_2_1, deduped_3_1;
	deduped_3_1 := Random( [ 0 .. n_1 ] );
	hoisted_2_1 := RandomMatrix( deduped_3_1, deduped_3_1, UnderlyingRing( cat_1 ) );
	morphism_attr_1_1 := Sum( [ 1 ], function ( c_2 )
	return c_2 * hoisted_2_1;
	end );
	return CreateCapCategoryMorphismWithAttributes( cat_1, CreateCapCategoryObjectWithAttributes( cat_1, Dimension, NumberRows( morphism_attr_1_1 ) ), CreateCapCategoryObjectWithAttributes( cat_1, Dimension, NumberColumns( morphism_attr_1_1 ) ), UnderlyingMatrix, morphism_attr_1_1 );
	end
	########

where the RandomObjectByInteger is implemented as follows:

CAP_project/LinearAlgebraForCAP/gap/precompiled_categories/MatrixCategoryPrecompiled.gi

Lines 4736 to 4743 in 74467a1

	##
	AddRandomObjectByInteger( cat,
	########
	function ( cat_1, n_1 )
	return CreateCapCategoryObjectWithAttributes( cat_1, Dimension, Random( [ 0 .. n_1 ] ) );
	end
	########

[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 aab7cbd. 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).