-
Notifications
You must be signed in to change notification settings - Fork 136
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
Normalization of polyratfun #172
Labels
question
Question about FORM
Comments
Hi Josh,
The problem is that there is an ordering “under normal circumstances” that is the traditional
ordering in FORM. If that would be all, the only problem would be that Normalize makes the
first term in the argument have coefficient +1, and MakeInteger does not bother about its sign.
Hence if you want to be certain you do things like
Normalize f;
MakeInteger f;
That gives a unique answer.
Then came the .cc files of Jan Kuipers and the PolyRatFun.
And in the libraries for polynomials there the order of the terms is exactly the opposite of the
traditional order. That is rather hard to change. This means that when you declare something
a polyratfun that was there already as a regular function with two arguments, it will originally
keep its traditional ordering, till the moment something happens and it has to redo the arguments.
Hence, until the arguments get their ‘dirty flag’ turned on, not much happens and you can force
that with some statements that do not do very much.
I know, this is not how it should be, but it would be quite some work to change things.
Alternatively you can experiment with
ON highFirst;
and those settings.
Cheers
Jos
… On 15 mrt. 2017, at 12:40, Josh Davies ***@***.***> wrote:
What determines the normalization and ordering of terms within a polyratfun?
I have two versions of an expression (loaded from save files) which are supposed to produce the same final result. I am comparing by diff-ing the printed expressions in the log file.
In a few terms, the polyratfun coefficients differ by, say, prf(a,b) vs prf(-a,-b). In other cases, the ordering of terms in multi-term arguments is different.
These effects can be influenced by removing other, distinct terms (which do always print identically in both cases). If I reduce my expression to the case with only the "bad" terms, they print identically.
It is not easy to provide a minimal example showing the problem, since it is part of a larger setup.
At the time of printing, the output of "On names;" is identical in both cases.
Do you have any ideas or suggestions to achieve a fixed normalization in all cases?
Thanks,
Josh.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#172>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLxEsa2KQOvaCKa-0zoPD04eqearE62ks5rl84ZgaJpZM4Md0-D>.
|
OK, thanks, I see what is happening now. By putting something like
in the module following that in which I introduce the polyratfun, everything is printed in a consistent way. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What determines the normalization and ordering of terms within a polyratfun?
I have two versions of an expression (loaded from save files) which are supposed to produce the same final result. I am comparing by diff-ing the printed expressions in the log file.
In a few terms, the polyratfun coefficients differ by, say, prf(a,b) vs prf(-a,-b). In other cases, the ordering of terms in multi-term arguments is different.
These effects can be influenced by removing other, distinct terms (which do always print identically in both cases). If I reduce my expression to the case with only the "bad" terms, they print identically.
It is not easy to provide a minimal example showing the problem, since it is part of a larger setup.
At the time of printing, the output of "On names;" is identical in both cases.
Do you have any ideas or suggestions to achieve a fixed normalization in all cases?
Thanks,
Josh.
The text was updated successfully, but these errors were encountered: