-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
equality of raw rings #1086
Comments
To find it, use the TAGS file in the d directory and find "===" with tags search in emacs. It is found in binding.d:
Now search for EqualEqualEqualS, finding this:
Now we know we have to find "equal", so search for "export equal" with arguments being of type Expr, finding this:
|
Are raw rings always unequal? Line 164 in 8b2bdcf
That doesn't seem to make sense because this is true:
How does it know the difference between |
Ah, yes, but the first line of the function
|
That line of code looks a little fishy at first glance, because we don't know yet that |
Are Also, what's your way of debugging the D language? Is there some sort of printerr command? |
It's a union type. Look at one of those components:
It's a struct with one component of type |
One way to debug D is with I don't know what a "printerr" command would do. |
PS: The main point of D is that it's a type-safe language, so it rarely needs debugging with gdb. Instead, one can insert print statements into the code temporarily to see what's going on, without any fear of causing the bug in your logic to evaporate. |
@DanGrayson is this solvable? At least a couple of of failing tests in the |
What problem needs solving? |
What do you mean? Are you saying that this isn't a bug? |
It depends on what "this" means, but the discussion above doesn't reveal a bug, as far as I can tell. |
Here is the bug from the text of the issue:
This, and similar assertions, are in many places in |
Oh. I think the test is wrong and the assertion can be deleted. |
On second thought, the underlying C++ code returns the same thing every time:
Hmm... |
Ah, it probably stopped working in 2010, when we started putting raw rings inside "raw ring cells" of type RawRingCell. Those are created each time, and the addresses differ. It wouldn't do any harm to make the equality test return true if the underlying raw rings are equal. That would be done by modifying the code for |
That code is now in the file |
Do you have any suggestions on how one might fix this? M2/M2/Macaulay2/tests/engine/raw-ring.m2 Lines 36 to 39 in 818b61c
|
Also, a number of tests have a header that says:
Testing internal things in order to avoid accidental regression is very important. I don't think they should be deleted. |
Something like this ought to work for those four assertions: diff --git a/M2/Macaulay2/d/equality.dd b/M2/Macaulay2/d/equality.dd
index 010fffd98..a56935aa2 100644
--- a/M2/Macaulay2/d/equality.dd
+++ b/M2/Macaulay2/d/equality.dd
@@ -161,7 +161,13 @@ export equal(lhs:Expr,rhs:Expr):Expr := (
)
else False
)
- is RawRingCell do False
+ is x:RawRingCell do (
+ when rhs
+ is y:RawRingCell do (
+ if x.p == y.p then True else False
+ )
+ else False
+ )
is x:RawMonomialIdealCell do (
when rhs
is y:RawMonomialIdealCell do ( |
Thanks! Most were fixed, except these two: (I added the 53 precision option) assert(raw RR_53 === rawRR(53))
assert(raw CC_53 === rawCC(53)) See the linked PR if you'd like to try it. This makes slightly more sense, given that a new ring seems to be created: Lines 85 to 97 in 818b61c
Is there an easy way to avoid making a ring that already exists? In particular, notice that each debug Core
hash RR_53 -- 1133379
hash RR_53 -- 1133379
hash raw RR_53 -- 21
hash raw RR_53 -- 21
hash rawRR(53) -- 22
hash rawRR(53) -- 23 I'll look into how |
I don't any point in arranging for |
Even though this is not very significant, I feel like trying to keep the language as functional as possible is worth the effort, and one part of that is that if a function returns the same object in memory, then the outputs of multiple calls should be equal. Also, I think using memoize for internal things might be troublesome. Do we do that anywhere else with raw objects at the moment? |
I doubt we do that elsewhere. Mike might prefer to cache them in the code for |
This isn't quite done yet. There are a couple of missing cases. |
@mikestillman can this be fixed? i1 : hash GF(2) === hash GF(2)
o1 = false |
That's a top level issue -- probably when writing the code, I figured that Galois files should be garbage collectable, the way polynomial rings are. |
I also want GF(p) === ZZ/p, but currently it is constructed as a GF(p^n). This is easy to fix, perhaps we should do so? |
I couldn't track down where
===
is defined for arbitrary objects. Is it usingequalmethod
inactors3.d
? I don't understand whatlookupBinaryMethod
andlookup1
are doing.The text was updated successfully, but these errors were encountered: