Open jodavies opened 7 years ago
Further, while trying to define
$test = 0/0;
causes a crash,
Symbol x,y,z;
Local F = x;
Bracket x,y,z;
.sort
$test = F[y]/F[z];
does not ($test gets the value 0). The same is true for
$test = 0/(1-1);
Another example to circumvent the division by zero error and get the (wrong) 0:
FORM 4.1 (Jun 10 2017, v4.1-20131025-355-g0bf5c58) 64-bits Run: Mon Jun 19 18:58:12 2017
S x,y;
L F = x/y * replace_(y,0,x,0);
P;
.end
F = 0;
I guess they are related to the subexpression substitution.
In this one you are on slippery ground. If it first replaces the x and then sees that you get zero, it never gets to replace the y. It is the same as taking the limit x->0,y->0 or the other way around.
Jos
On 19 jun. 2017, at 19:00, Takahiro Ueda notifications@github.com wrote:
Another example to circumvent the division by zero error and get the (wrong) 0:
FORM 4.1 (Jun 10 2017, v4.1-20131025-355-g0bf5c58) 64-bits Run: Mon Jun 19 18:58:12 2017 S x,y; L F = x/y * replace_(y,0,x,0); P; .end
F = 0; I guess they are related to the subexpression substitution.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/202#issuecomment-309502499, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEurXHpzi90v_3g8H7VLVnc4xfptPks5sFqkrgaJpZM4N-gAZ.
To be more precise about what happens:
In all these cases both replacements (the dollars, the F[z], etc) are made simultaneously.
But now comes the point: 0 is not a value in a sense: there is no term.
Hence when you have $x/$y it becomes no term when it does the $x. If it does the $y first
that is inside a denominator function which than happily has a zero argument (because inside a
function it does become zero. If an expression has no terms it is seen as zero.
Hence if the $y goes first you get $x/den(0) after which the $x gives no terms.
The normalization is done only after there are no more subexpressions to be substituted.
(of course $x’/
$y’ would give a crash).
This behaviour is very fundamental in FORM. Hence you should guard yourself against this kind of order of ‘limits’.
Jos
On 19 jun. 2017, at 19:33, Jos Vermaseren t68@nikhef.nl wrote:
In this one you are on slippery ground. If it first replaces the x and then sees that you get zero, it never gets to replace the y. It is the same as taking the limit x->0,y->0 or the other way around.
Jos
On 19 jun. 2017, at 19:00, Takahiro Ueda <notifications@github.com mailto:notifications@github.com> wrote:
Another example to circumvent the division by zero error and get the (wrong) 0:
FORM 4.1 (Jun 10 2017, v4.1-20131025-355-g0bf5c58) 64-bits Run: Mon Jun 19 18:58:12 2017 S x,y; L F = x/y * replace_(y,0,x,0); P; .end
F = 0; I guess they are related to the subexpression substitution.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/202#issuecomment-309502499, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEurXHpzi90v_3g8H7VLVnc4xfptPks5sFqkrgaJpZM4N-gAZ.
The following script should crash, but instead yields
test = 0;
.If $num is set to any non-zero value or expression, FORM gives
Division by zero during normalization
as expected.Thanks, Josh.