FactorAlgorithmBase#factor() don't add `BigInteger.ONE`

[axkr]

In FactorAlgorithmBase don't add BigInteger.ONE as factor only add prime factors:

	public SortedMultiset<BigInteger> factor(BigInteger N) {
		SortedMultiset<BigInteger> factors = new SortedMultiset_BottomUp<BigInteger>();
		// first get rid of case |N|<=1:
		if (N.abs().compareTo(I_1)<=0) {
			if (!N.equals(BigInteger.ONE)) {
				factors.add(N);
			}
			return factors;
		}
		// make N positive:

[TilmanNeumann]

This is about conventions I guess.
The current solution is: If N is -1, 0, or 1, then return it as the single "factor".
Your proposition means that we`ld have to return an empty set if N=1.
Actually I do not see the improvement. Please help me ;-)

[danaj]

Some thoughts...

It seems important that in all cases the product of the returned vector equals the input. Given the usual convention that the product of an empty set returns 1, then we definitely need to be returning -1 and 0 for the inputs -1 and 0 respectively if we allow them at all. But it is our choice of returning 1 or an empty set for 1. The empty set seems to be the more mathematical answer. E.g. OEISWiki.

In my software I chose to emulate Pari/GP and go with the empty set for an input of 1. Sage returns 1; Errors given an input of 0; and negative inputs seem to be handled similar to other libraries. Julia's Primes.jl returns -1,0,1 respectively which looks like what this library is doing.

My reading of the reasoning behind preferring the empty set makes me think this is predicated on only allowing positive integer inputs. As soon as zero and/or negative inputs are allowed then it doesn't seem like it matters.

[TilmanNeumann]

Thanks for the elaborated consideration, Dana. I changed it as proposed.