Paul Zinn-Justin
Paul Zinn-Justin
this is what I get: ``` i1 : errorDepth=0 o1 = 0 i2 : M = sub(matrix {{1},{0}}, ZZ/32003) o2 = | 1 | | 0 | ZZ 2 ZZ...
As discussed in zulip, I think 1bcd8767f71929652979ae7f579c57d6d69536dd should be reverted. I'm not sure it solves any of the issues raised in this thread about methods (whose hashes are AFAICT not...
OK I see -- it has not changed the hash of *actual* methods -- but `MethodFunctionWithOptions` isn't a method. Those are now getting identical hashes. edited: after checking, `MethodFunction` is...
in case other people are wondering, the pre-commit situation was as follows: every `FunctionClosure` got a new hash number when it was parsed, according to `convertr.d` ``` is a:Arrow do...
> Though I agree that we should come up with a different fix than what Dan implemented. I think my preference is for the hash function of a function closure...
can we move the definition of `MethodFunctionWithOptions`, etc, to the d level? the only way I can think of at the moment.
Certainly returning an Ideal would make a lot more sense, but I'm afraid it might break existing code. (a hacky way to avoid the latter would be to define `ideal...
what happens when you remove the check?
This issue is particularly bad with `AssociativeAlgebras`: ``` i1 : needsPackage"AssociativeAlgebras" o1 = AssociativeAlgebras o1 : Package i2 : R=QQ o2 = R o2 : FreeAlgebra i3 : (last coefficients(1/3*x))_(0,0)...
In constrast, `leadCoefficient` does give the coefficient in the coefficient ring, as should be.