axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] any?, member?, ...


From: William Sit
Subject: Re: [Axiom-developer] any?, member?, ...
Date: Wed, 23 Jun 2004 11:03:43 -0400


Martin Rubey wrote:
> 
> I noticed that these function evaluate the predicate for all elements of the
> argument list, which I find rather strange. For example:
> 
> (2) -> any?(i+->(output(i);(i=1)::Boolean),[1,2,3])
>    1
>    2
>    3
> 
>    (2)  true
>                                                                 Type: Boolean
> 
> Wouldn't it be sensible to define these functions so that they exit when the
> result is determined, i.e., instead of
> 
>      any?(f, c)           == _or/[f x for x in parts c]
>      every?(f, c)         == _and/[f x for x in parts c]
> 
> do
> 
>      any?(f, c) ==
>        for x in parts c repeat
>          if f x then return true
>        false
> 
>      every?(f, c) ==
>        for x in parts c repeat
>          if not f x then return false
>        true
> 
> It seems that for TREE, some shortcircuiting is done:
> 
>     any?(fn, t) ==  ---bug fixed
>       t case empty => false
>       fn value t or "or"/[any?(fn, c) for c in children t]
>     every?(fn, t) ==
>       t case empty => true
>       fn value t and "and"/[every?(fn, c) for c in children t]
> 

That was my thoughts when I read your preliminary patch 3148:

>      dvdsum(l, x) ==
>        x = retract(y := third l)@SE => 0
> -      k := retract(d := second l)@K
> -      differentiate(h := third rest rest l,x) * eval(f := first l, k, h)
> -        - differentiate(g := third rest l, x) * eval(f, k, g)
> -             + opdsum [differentiate(f, x), d, y, g, h]
> +      if member?(x, variables(h := third rest rest l)) or 
> +         member?(x, variables(g := third rest l)) then
> +        dm := dummy
> +        kernel(opdiff, [eval(opdsum(l), x::F, dm), dm, x::F])
> +      else
> +        opdsum [differentiate(first l, x), second l, y, g, h]
>  

Note that g would not have been defined in some cases in the last line if the
operator OR does not evaluate all its clauses first. I was about to suggest that
you define h and g outside of the IF statement to make it more robust, but
decided it's ok. I was under the impression also that exactly how the logical
operators evaluate was compiler/optimisation dependent, but I wasn't sure.

In general, I would prefer not to use side-effects in programming in arguments
for logical operators.

William




reply via email to

[Prev in Thread] Current Thread [Next in Thread]