Skip to content
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

Remove editlevels #36

Closed
wants to merge 55 commits into from
Closed

Remove editlevels #36

wants to merge 55 commits into from

Conversation

pippijn
Copy link
Collaborator

@pippijn pippijn commented Aug 1, 2013

See #21.

pippijn added 30 commits July 31, 2013 03:04
Updated ALDOR_F_LibExportNotFound error message
and allows AXL_ as well as ALDOR_ message prefixes
pippijn added 25 commits August 1, 2013 11:07
This edit has been turned into a compiler option: -Wnew-hcodes
Here is the comment from editlevels.h:

Edit level AXL_EDIT_1_1_13_18 has been returned to the list of active edits.
It still causes problems for Basicmath DUP, but it solves the issue where maps
and packed maps were being given the same hash value when the only difference
in the maps was the position of the map symbol.  For example (I, I) -> (I, I)
was getting the same hash code as (I) -> (I, I, I) and (I, I, I) -> (I).

The problem with Basicmath DUP can be seen when * is applied to acc and result
in CantorZassenhausFactorizationPackage (located in
$BMROOT/src/polypkg/factorczpkg.as).  When acc is ? and result is 1, (both acc
and result being of type U), the multiply invoked is (r: R) * (x : %) : %
rather than (x : %) * (y : %) : %.  This results in a large integer times ?
being returned, rather than 1*?.

Applying this edit appears to be revealing another bug in the compiler that
has yet to be isolated to a simple test case.  (The Basicmath DUP behaviour
is illustrated by Basicmath test duptest19.as).  It does not appear to be a
result of a hash code collision under the new system as several alternative
code computations were tried providing the same result.
@pbroadbery
Copy link
Member

Are you going to merge these changes? - they look good to me (although
I've really only eyeballed them).

Peter

@pippijn
Copy link
Collaborator Author

pippijn commented Aug 3, 2013

yes, I was waiting for someone to review them before I do

@pippijn pippijn closed this Aug 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants