exp(3) and exp(1)^3 are displayed the same

14 views
Skip to first unread message

Qian Yun

unread,
Dec 27, 2023, 5:20:11 AM12/27/23
to fricas-devel
exp(3) and exp(1)^3 are displayed as the same thing.

So it is difficult to distinguish them just by looking at OutputForm.

I propose that exp(1)^3 should be displayed with parenthesis around %e.

One approach will be changing
exp(1)::OUTFORM from %e to (EXP 1)
exp(n)::OUTFORM from (^ %e n) to (EXP n)

And tweaking interp/output.boot accordingly.

- Qian

Waldek Hebisch

unread,
Dec 27, 2023, 11:28:37 AM12/27/23
to fricas...@googlegroups.com
On Wed, Dec 27, 2023 at 06:20:08PM +0800, Qian Yun wrote:
> exp(3) and exp(1)^3 are displayed as the same thing.
>
> So it is difficult to distinguish them just by looking at OutputForm.
>
> I propose that exp(1)^3 should be displayed with parenthesis around %e.

I do not think that this is good idea. exp(3) and exp(1)^3
mathematically are the same thing, so there is not much harm
in displaying them as the same thing. People may use them
to generate LaTeX, so we really want them to look the same.

We have cases when thing loking equal lead to different
results, but then there are tricks to see what is happenig.
One can look at kernels or coerce to InputForm.

--
Waldek Hebisch

Ralf Hemmecke

unread,
Dec 27, 2023, 4:48:15 PM12/27/23
to fricas...@googlegroups.com
> I propose that exp(1)^3 should be displayed with parenthesis around %e.

I oppose. Even though you would make %e^3 distinguishable from exp(3) or
exp(1)^3, I oppose against adding parentheses where none are needed.
Parentheses should be added by the formatting routine and (if possible)
not be stored in the OutputForm datastructure itself.

> One approach will be changing
>    exp(1)::OUTFORM  from %e to (EXP 1)
>    exp(n)::OUTFORM  from (^ %e n) to (EXP n)

I would actually not really be against showing exp(n) as "exp(n)" in the
output. But as Waldek said %e and exp(1) are only two different
representations of the same thing.

And we also have this...

%%% (14) -> operator first kernels (%e^n)

(14) exp
Type: BasicOperator
%%% (15) -> argument first kernels (%e^n)

(15) [n]
Type: List(Expression(Integer))
%%% (16) -> argument first kernels (exp n)

(16) [n]
Type: List(Expression(Integer))
%%% (17) -> operator first kernels (exp n)

(17) exp
Type: BasicOperator
%%% (20) -> kernels (exp(1)^n)

n
(20) [%e ]
Type: List(Kernel(Expression(Integer)))
%%% (21) -> kernels (exp(n))

n
(21) [%e ]
Type: List(Kernel(Expression(Integer)))


Do you see exp(1)^3 and exp(3) treated differently somewhere? Or even
stored differently?

Ralf

Qian Yun

unread,
Dec 27, 2023, 6:35:01 PM12/27/23
to fricas...@googlegroups.com
In exp(1)^n, the ^ (%power) operator examines the base and expt to
do certain transformation, for example exp(1)^n => exp(n).

It does not do such transformation for integer (to prevent messing
up kernel for other functions, e.g. limit):
exp(1)^3 =!> exp(3)

(3) -> mainKernel exp 3

3
(3) %e

(4) -> mainKernel ((exp 1)^3)

(4) %e

(5) -> exp(3)-(exp 1)^3

3 3
(5) %e - %e


On 12/28/23 05:48, Ralf Hemmecke wrote:
>> I propose that exp(1)^3 should be displayed with parenthesis around %e.
>
> I oppose. Even though you would make %e^3 distinguishable from exp(3) or
> exp(1)^3, I oppose against adding parentheses where none are needed.
> Parentheses should be added by the formatting routine and (if possible)
> not be stored in the OutputForm datastructure itself.

Let me be clear: a normal %e will be printed without parentheses,
only when printing under a power, there are parentheses.

- Qian

Ralf Hemmecke

unread,
Dec 27, 2023, 6:54:06 PM12/27/23
to fricas...@googlegroups.com
> (5) -> exp(3)-(exp 1)^3
>
>           3     3
>    (5)  %e  - %e

OK. Thanks.

Not wrong, but you must admit that such things look completely confusing
to users. As a first-timer I would claim that FriCAS is a rather weak
system if it doesn't know how to automatically simplify that. (Yes, I
know that one can construct similar things in Maple and Mathematica.)
Still it looks sad if a CAS "fails" on such simple things.

I think things like the above deserve an entry in the FAQ or maybe I
collect a few things into a new file at

https://fricas.github.io/fricas-notebooks/

Ralf

Waldek Hebisch

unread,
Dec 27, 2023, 7:10:54 PM12/27/23
to fricas...@googlegroups.com
On Wed, Dec 27, 2023 at 10:48:12PM +0100, Ralf Hemmecke wrote:
>
> And we also have this...
>
> %%% (14) -> operator first kernels (%e^n)
>
> (14) exp
> Type: BasicOperator
> %%% (15) -> argument first kernels (%e^n)
>
> (15) [n]
> Type: List(Expression(Integer))
> %%% (16) -> argument first kernels (exp n)
>
> (16) [n]
> Type: List(Expression(Integer))
> %%% (17) -> operator first kernels (exp n)
>
> (17) exp
> Type: BasicOperator
> %%% (20) -> kernels (exp(1)^n)
>
> n
> (20) [%e ]
> Type: List(Kernel(Expression(Integer)))
> %%% (21) -> kernels (exp(n))
>
> n
> (21) [%e ]
> Type: List(Kernel(Expression(Integer)))
>
>
> Do you see exp(1)^3 and exp(3) treated differently somewhere? Or even stored
> differently?

Well, there is subtlety. One trap is:

(26) -> %e^3 - exp(3)

3 3
(26) - %e + %e
Type: Expression(Integer)
(27) -> unparse(%::InputForm)

(27) "(-1)*exp(3)+exp(1)^3"
Type: String

Note: there is difference between integer exponents and "symbolic"
exponents. Preseving integer exponents is crucial to things like
'normalize' which are at core of many algorithms. OTOH "symbolic"
exponents can be changed. Compare:

(28) -> exp(n)^3

n 3
(28) (%e )
Type: Expression(Integer)
(29) -> exp(3)^n

3 n
(29) %e
Type: Expression(Integer)

In the first case we need exponet 3 for correct computations.
In the second we can combine exponents in default transformation.

--
Waldek Hebisch
Reply all
Reply to author
Forward
0 new messages