[Date Index]
[Thread Index]
[Author Index]
Re: Unwanted Recursion
*To*: mathgroup at smc.vnet.net
*Subject*: [mg120095] Re: Unwanted Recursion
*From*: Kambis Veschgini <k.veschgini at thphys.uni-heidelberg.de>
*Date*: Fri, 8 Jul 2011 04:52:50 -0400 (EDT)
*References*: <iv1a95$sjl$1@smc.vnet.net> <iv4662$f9m$1@smc.vnet.net>
On 2011-07-07 13:44:02 +0200, Simon said:
> Writing these type of replacement rules for functions with the Flat can
> be confusing. This is because of how Flat (and OneIdentity) act in the
> Mathematica pattern matching algorithms.
>
> There are two (AFAIK) options:
> 1) Don't use Flat & OneIdentity in your anticommutative multiplication.
> Instead implement these properties using your own patterns. See e.g.
> http://library.wolfram.com/infocenter/Conferences/325/
> 2) Don't write DownValue / UpValue rules for p[a_] and p[]. Instead,
> manually apply those simplifications at the end of each calculation.
> This is probably the more optimal way to go. It can even be automated
> with
> $Post=(#/.{p[a_]:>a,p[]->1}&)
>
> If anyone has a more direct solution (or black magic solution) to
> combining the Flat attribute and p[]=1 type definitions, I'd be
> interested in seeing them.
Mathematicas built in functions like NonCommutativeMultiply, Plus,
Times are flat and they behave as expected. The attributes help
mathematica do better pattern matching and if I'm not meant to use them
here I don't even understand why there are there. I don't care about
the rules beeing confusing as long as the behaviour is deterministic
and well documented.
Prev by Date:
**Re: Contour ColorFunction in a ParametricPlot**
Next by Date:
**Re: Grouping terms under the radical**
Previous by thread:
**Re: Unwanted Recursion**
Next by thread:
**Re: Unwanted Recursion**
| |