<d​imalinux:monero.social> So is this the best place to ask questions about the FCMP++ optimization competition? I'm starting with the helioselene code and looking at the code coverage of the tests. Is there functionality that should be preserved even though it is not being tested, or should I feel free to delete any code that has zero coverage by both the required and optional tests?

<s​yntheticbird:monero.social> jberman: jeffro256

<3​21bob321:monero.social> New room inbound

<j​berman:monero.social> @dimalinux you should feel free to delete code that has no coverage by required tests. You don't need to pass optional tests. Is there something you see that you think should be preserved that the required tests didn't cover?

<d​imalinux:monero.social> Most of the stuff seemed like functionality that Monero wouldn't use. Like From conversions with different integer types. Other stuff like this I wasn't sure:

<d​imalinux:monero.social> ```

<d​imalinux:monero.social> impl HelioseleneField {

<d​imalinux:monero.social> /// Perform a wide reduction, presumably to obtain a non-biased Helioselene field element.

<d​imalinux:monero.social> pub fn wide_reduce(bytes: [u8; 64]) -> HelioseleneField {

<d​imalinux:monero.social> HelioseleneField(Residue::new(&reduce(U512::from_le_slice(bytes.as_ref()))))

<d​imalinux:monero.social> }

<d​imalinux:monero.social> }

<d​imalinux:monero.social> ```

<j​berman:monero.social> Fair question. I would say it's within the spirit of the wasm-cycles test for `random()` to yield a reasonable result, which expects a `reduce()` that yields a reasonable result, so I would recommend implementing a reduction algorithm. But no you should be fine to delete that code and get rid of the dependency on `crypto-bigint` if you want

<a​ck-j:matrix.org> dimalinux: may I ask where you heard about the competition? We are working on the marketing effort