Name: Frederik Orellana (email_not_shown)
Date: 09/05/00-02:56:22 PM Z


Hello Vadim!

>Hello, Frederik!
>
>I send a little corrected notebook from previous letter. Formerly I
>used there not very pertinent symbols x, x1, x2, which are washed out
>by DotSimplify from Dot inside ComplexConjugate. So it looked a little
>confusedly. Here I simply replaced these x-s by DirackGammas for better
>presentability.

Good, will look at it and incorporate it in the next update.

>
>Then I send corrected wersion of FeynCalc2FORM function. In notebook
>FeynCalc2FORMBugz.nb you can find examples and explanations.
>In FeynCalc2FORM.m I fixed several bugz, nothing more
>(I wrote, that I work on extensions for writing FORM-files, and, may
>be, executing and reading, if I'll find it usefull. But it is in
>progress still)

Very good! Will look at it too. Neither Rolf nor I know FORM very
well, so its nice to have others contribute there.

>
>Now I want to ask a pair of questions and give some proposals.
>You can place them on forum.
>
>First - about FeynArts + FeynCalc. How to use them together. If we
>patch FeynArts with your perl-script from Phi, there will be new
>notations for Spinors, FeynAmps etc. In that case I think it would be
>good to add supporting of these notations to FeynCalc functions that
>deels with amplitudes (kind of internal translation to usual Spinors,
>FeynAmps etc.).

I'm working at this right now. Don't use the old Phi stuff, a new
version is being incorporated into FeynCalc. Also, I'm reusing the
FeynCalc names (and contexts) like FeynAmp etc. in my patch to
FeynArts so as not to have two names for each quantity. I expect an
update with your stuff, several bugfixes and Phi + FeynArts patch to
be ready in a couple of weeks.

>And in FeynCalc.m I saw some workarounds with
>$LoadFeynArts and HighEnergyPhysics`FeynArts`. I had not enough time
>to gain an understanding of all this...
>But how do you manage with FeynArts + FeynCalc in convenient way?

Its outdated. I recommend waiting two weeks and using the patched
FeynArts mentioned above.

>Second - about SimplifyPolyLog. What does words "assuming that the
>variables occuring in the Log and PolyLog functions are between 0
>and 1" means? That any variable, occuring in PolyLog's (Log's)
>argument, is assumed to be in [0,1]? But if we have rather complex
>argument with several variables? What are boundaries of validity of
>SimplifyPolyLog? If I understand right, to be sure in the result,
>in arguments must be ONE variable, which is definitely in [0,1].
>Else there could arise ambiguites with Imagine terms. But what can
>I do, if I have complex variables. Many of formulas in the replacement
>table of SimplifyPolyLog become not valid in that case (at least for
>Log. I didn't deepen in PolyLog formulas, but when there is I*Pi, it
>is very probably that formula will not be valid).
>It would be great to have such simplifying function for PolyLogs
>(only) with general args, which may leave simplifying of Logs to
>discretion of user.

This is not something I know much about. Rolf is also on the mailing
list and should answer if he has time. Otherwise I'll look at it.

>
>One more remark: one of replacements in SimplifyPolyLog's replacement
>table (line 341) have not patterned x in the left side.
>So I send and SimplifyPolyLog.m with this small correction.
>
Good.

Thanks for your help and good luck.

Frederik



This archive was generated by hypermail 2b29 : 09/04/20-12:55:05 AM Z CEST