The conditional expression idea was called "Provisos" in Axiom. It could be multi-branched with list of [ condition | expression ] terms. The idea was mentioned as a project goal in 2003-08.txt
There was extensive debate about the idea. Search the email thread in the Axiom download, specifically in axiom/book which contains almost all of the emails up to October 2020. I tried to make it work but it raised more controversy than expected. Tim On Wednesday, June 17, 2026 at 7:12:25 PM UTC-4 oldk1331 wrote: > Thanks for the nice explanation. > > Yes, it requires extra care for zero divisors. > > In this case, the denominator of x1,x2 does not multiply > to zero, so we can get sensible result if we interpret > that the branch is chosen to avoid division by zero. > > For 'reduc', the attached patch changes the evaluation > order: reduction over algebraic kernels first, > do the division at the end. > > This will make (x1-x2) return 0, which make the system > a little bit more consistent. > > - Qian > > On 6/18/26 4:20 AM, Waldek Hebisch wrote: > > On Wed, Jun 17, 2026 at 05:20:27PM +0800, Qian Yun wrote: > >> x1:=(y-sqrt(y^2))/(x-sqrt(x^2)) > >> x2:=1/(y+sqrt(y^2))*(x+sqrt(x^2)) > >> (x1=x2)$EXPR(INT) > >> x1-x2 > >> > >> > >> So (x1=x2) was false before my recent commit 7af446cb, > >> afterwards it becomes true. > >> > >> I think that is acceptable. > >> > >> However (x1-x2) is not zero, before/after this commit. > >> > >> That's caused by the '/' in 'reduc', common gcd factor > >> is removed from numerator on the first loop. > >> > >> Shall we try to fix it? > >> > >> Or reject it because it contains dependent algebraic kernels? > > > > Dependent kernels mean that we do not have a field, but basic > > things should still work properly. More precisly, sqrt(x^2) > > means extention by element s such that s^2 = x^2. This is > > well defined and gives ring with zero divisors. For such > > ring we may consider full ring of fractions, that is set > > of fractions n/d such that d is not a zero divisor. x1 > > and x2 above are problematic because in both cases denominator > > is a zero divisor. Both x1 and x2 make sense if we restrict > > branches of square root so that denominators are non zero. > > If we do that both for x1 and x2, then we get value zero > > for both. So possible result of x1 = x2 could be > > > > [true | x = -sqrt(x^2) and y = sqrt(y^2)] > > > > and for x1 - x2 > > > > [0 | x = -sqrt(x^2) and y = sqrt(y^2)] > > > > where I used '[a | b]' to denote that result a is valid under > > condition b. > > > > Without conditional expressions (which we do not have ATM) we > > could try to reject x1 and x2. This is expensive but doable in > > algebraic cases. But if we have logarithms and want to reason > > about branches of logarithms, then problem in general is > > undecidable (with conditional expressions we could return > > problematic conditions to the user, without we need to decide). > > > > Rejecting x1 and x2 is also problematic because we could create > > package(s) which do something sensible about branches. If > > x1 and x2 were rejected we could not create them as expressions > > and pass to such a package, so we would need a new domain > > allowing x1 and x2. > > > > Currently probably handling of x1 and x2 does not matter too much, > > as current Expression is not able to give sensible result for x1 = x2 > > or x1 - x2. But rejecting them is also rather unattractive. > > > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/79fac58d-f07f-4855-8d51-3feb6ba4ee77n%40googlegroups.com.
