On 23 May 2017 at 11:14, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > > This function could be useful. But there is problem with current > FriCAS spirit: we have notion of canonical representation of a > prime. Gcd code take some effort to return canonical version, > which in case of fields means 1.
Could you explain why you consider 1 to be canonical in this case? > I am not sure if/what breaks > with changed definition. In principle the so no warranty for > getting canonocal version, so existing code should work. There is no difference in the results of the input test files. > But there are many places when we have test for gcd equal to 1. > This code would take different branch with changed definition, > possibly leading to wrong result or loss of efficiency. > In fact gcd is compared to 1 in only 8 places in the spad source code: ffcat.spad, ffnb.spad, ffpoly.spad, ffx.spad, intfact.spad, padiclib.spad. > As Ralf wrote, your definition is more expensive to compute > than current one. And depending on need either the current > one (giving canonical version) or new one (extending gcd to > fractions) is more useful. So it is probably better to have > a separate function, say 'fractionGcd'. > There is no detectable difference in the run time of the test scripts. gcd and lcm in Fraction is called in during the execution of the following input files: allfact.input bugs2007.input calculus2.input ch.input danzwill.input defintef.input divisor.input fixed.input ideal.input intef.input integ.input mapleok.input noonburg.input poly.input r20abugs.input test.input tutchap3.input On 23 May 2017 at 11:51, Ralf Hemmecke <r...@hemmecke.org> wrote: > If at all, I'd be in favour of such a new function fractionGcd. > However, my question is whether it is really worth implementing a new > function. Yes, it's convenient, but any user can define > > fractionGcd(x,y) := gcd(numer x, numer y) / lcm(denom x, denom y) > > as a simple oneliner if he/she really needs such a function. As you say, it the issue is only one of convenience then I don't think introducing new functions for this purpose is worthwhile. In fact I think having two different definitions of gcd for quotient fields is undesirable. > > How useful is this function for the general Fraction constructor > if in an instance Fraction(S) the S is something like PrimeField 7? > The interpreter says: "Fraction(PrimeField(7)) is not a valid type." but perhaps this could be built in SPAD. > Has anyone a good use case for such a fractionGcd function > other than just convenience? > I would like to turn that question around: Does anyone have a good use case for the current definition of gcd in Fraction? Bill Page. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
