Nemocas
Support all Number types as RingElements
@jmichel7 has reported that SafeInteger is another Julia integer type that we should support. He also has a cyclotomic number package which would be supported if our RingElement could accept any Number type.
We can't do any better for FieldElement, but at least it would help some others get some more use out of our packages.
Hmm, I think this is a good idea.
There are some functions that we expect and that we define e.g. for Float64 or BigInt.
Since they probably don't want to make AA a dependency, we could have a generic parent object to accommodate for the lack of parent(::SafeInteger) = GenParent{SafeInteger}(). Similar for the other functions, we could create some generic fallbacks. This should work!
Of course my approach only works if the parent is uniquely determined by the type, which is for example the case for the types @jmichel7 is providing. I don't think we can do better in general.
Yeah @jmichel7 (note spelling) strongly suggested that we make it easier (even trivial) for other people to use our generics. For example a macro which takes the name of the type and automatically makes it a RingElement or FieldElement (by wrapping it), and to implement some sensible fallbacks for our Ring/Field interfaces so the user needs to implement far fewer functions to get things initially working.
He also suggested that we not require definition of needs_parenthesis, canonical_unit, printed_with_minus and so on, but just look at the output printed by their show function and see if there are any pluses. I'm not convinced this can be made to work generally, but I don't have a counterexample to his suggestion presently.
Actually, if I recall correctly, @jmichel7's cyclotomic types are parameterised. So I'm not sure about the unique parent thing, even in his case.
I don't even think that we need wrapper. I want to try to cook something up and see if it works with his cyclotomic elements.
The big problem is his cyclotomics are field elements, so things like linear algebra and polynomial arithmetic will be slow if they are treated only as RingElements.
I'll also send you a copy of the current interface wrapper I wrote (which does work).
@thofma It's made more complicated by the fact that in some cases they will be FieldElements and in other cases they have to be RingElements. I didn't try to solve that problem in my interface code, which I just sent you.
@thofma What I mean is that Z[\zeta] is the maximal order of Q[\zeta] and he supports both.
I think before we go ahead with this ticket, we should make a decision as to whether we really want to do it or not. The project has moved on a lot since this was opened.
What are our (I mean Oscar) costs and benefits? Clearly: more users are good. However, more users complaining that AA does not work for some entertaining imprecise non-domain is bad.... So I don't know. Allowing e.g. Int as RingElements (which we do "support") is already dangerous as this s really Z/2^64Z with signed remainders. Allowing this unchecked to be fed into complex algorithms is dangerous. (e.g. isdomain_type(Int) yields true...) Any thoughts? @jmichel7 knows what he is doing, he is low risk. However, there are others...
I agree. We don't currently need this ourselves, and don't directly benefit. However it may be useful to the Julia community. If someone wants to step up and make this work without breaking anything for us, have at it. I've added the JuliaCommunity tag to that end.