oldk1331 wrote:
> 
> The problem is about branch cuting:
> 
> For Integers and Fractions, (-1/8)^(1/3) gives AlgebraicNumber
> containing (-1)^(1/3), avoids branch cuting.
> 
> For numeric computing, for example Float, I think it's better
> to have signature:
>     ^ : (%, Fraction Integer) -> %
> aka keep current definition of '^'.
> 
> People can use "((-0.125)^(1/3))$Complex Float" to get principle
> complex value.
> 
> So the patch I propose is:
> 
> diff --git a/src/algebra/mkfunc.spad b/src/algebra/mkfunc.spad
> index 963e4727..431d9dab 100644
> --- a/src/algebra/mkfunc.spad
> +++ b/src/algebra/mkfunc.spad
> @@ -425,13 +425,15 @@
>        (u := mkLispList rest l) case "failed" => "failed"
>        ll := u::List(INF)
>        streqlist?(op, ["+","*","/","-"]) => convert(concat(op, ll))@INF
> -      streq?(op, "^") => gencode("EXPT", ll)
>        streqlist?(op, ["exp","sin","cos","tan","atan",
>           "log", "sinh","cosh","tanh","asinh","acosh","atanh","sqrt"]) =>
>              gencode(upperCase string symbol op, ll)
> +      -- Common Lisp's definition of "^" is different from FriCAS when
> +      -- first argument is negative, so stop generating code for this case.
> +      streq?(op, "^") => "failed"
>        streq?(op, "nthRoot") =>
>          second ll = convert(2::Integer)@INF =>gencode("SQRT",[first ll])
> -        gencode("EXPT", concat(first ll, [1$INF / second ll]))
> +        "failed"  -- same as "^"
>        streq?(op, "float") =>
>          a := ll.1
>          e := ll.2
>
 
This patch causes failure in tutchap4.input.  Arguably, test
in tutchap4 is wrong, because it uses roots of negative
numbers:

S3 := eval(S,[A=1,k=1,c=0.1])

   (6)
                                     +-------+
            +-------+         0.05 t\|- 399.0  - 0.05 t
       (0.5\|- 399.0  + 0.5)%e
     + 
                                       +-------+
            +-------+         - 0.05 t\|- 399.0  - 0.05 t
       (0.5\|- 399.0  - 0.5)%e
  /
      +-------+
     \|- 399.0
                                                      Type: Expression(Float)

However, this is wrong more or less the in the same way as
the x^(1/3) test that you try to make to work.  So the change
does not look as improvement: we make one borderline case
work at expense of another borderline case...

-- 
                              Waldek Hebisch

-- 
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to