Re: [fricas/fricas] eec2f4: Put no space between function name and arguments

2 views
Skip to first unread message

Ralf Hemmecke

unread,
Jul 3, 2024, 11:22:02 AMJul 3
to fricas-devel
Hi Waldek,

Your patch gives good visual results, but I do not think that it is
logically right.

%%% (156) -> h := operator 'h

(1) h
%%% (2) -> (h(x)::OutputForm pretend SExpression)

(2) (h x)

%%% (3) -> function(sin x, 'f, 'x)

(3) f

%%% (4) -> f :: OutputForm pretend SExpression

(4) (CONCATB (CONCAT f (PAREN x)) == (sin x))

I would rather have thought that

(CONCATB (f x) == (sin x))

would be a logically better OutputForm, don't you think?
Similar for more parameters. Only the cases where there is a condition
must be explicitly be done with PAREN.

In fact, one could also argue that

g(n, t) | (n > 1 and odd?(n) and t > 9) == tanh(n) + t

would be a "valid" outcome. I wouldn't, however, suggest it, since
FriCAS allows foo(x | x>0) as input when defining functions, so I am
fine if the conditional case is shown as it is now.

With the definition

flx x ==> lines(format(format(x::OutputForm)$Formatter(FormatLaTeX)))

we get

(5) -> flx f

["\SYMBOL{f}\PAREN{\SYMBOL{x}}\ \SYMBOL{==}\
\FUNCTION{\sin}{\SYMBOL{x}}"]

In other words, the OutputForm cannot be recognized as function, because
it declares itself just as the juxtaposition of a symbol and a
parenthesized symbol and not as a function, as it could/should be.

Ralf

On 7/3/24 16:45, hebisch wrote:
> Branch: refs/heads/master
> Home: https://github.com/fricas/fricas
> Commit: eec2f4bf0c5ca391f454e651be4ee2f0f06512b0
> https://github.com/fricas/fricas/commit/eec2f4bf0c5ca391f454e651be4ee2f0f06512b0
> Author: Waldek Hebisch <c...@fricas.org>
> Date: 2024-07-03 (Wed, 03 Jul 2024)
>
> Changed paths:
> M ChangeLog
> M src/interp/i-output.boot
>
> Log Message:
> -----------
> Put no space between function name and arguments

Waldek Hebisch

unread,
Jul 3, 2024, 12:32:56 PMJul 3
to fricas...@googlegroups.com
On Wed, Jul 03, 2024 at 05:21:59PM +0200, Ralf Hemmecke wrote:
> Hi Waldek,
>
> Your patch gives good visual results, but I do not think that it is
> logically right.
>
> %%% (156) -> h := operator 'h
>
> (1) h
> %%% (2) -> (h(x)::OutputForm pretend SExpression)
>
> (2) (h x)
>

The above would need seprate fix.

> %%% (3) -> function(sin x, 'f, 'x)
>
> (3) f
>
> %%% (4) -> f :: OutputForm pretend SExpression
>
> (4) (CONCATB (CONCAT f (PAREN x)) == (sin x))
>
> I would rather have thought that
>
> (CONCATB (f x) == (sin x))
>
> would be a logically better OutputForm, don't you think?

Well, "no parenthesis for single argument" is a shortcut and
clearly leads to gratitious differences. So I think that
current form is better. Of course, in "logical" way we would
have something like

(Infix == (Apply f x) (Apply sin x))

But current OutputForm does not have such "logical" operators and
instead has 'CONCAT' and 'CONCATB'. With limitation of OutputForm
current output is resonably close to logical form. At least it
is closer to logical form than output before the change.

> Similar for more parameters. Only the cases where there is a condition must
> be explicitly be done with PAREN.
>
> In fact, one could also argue that
>
> g(n, t) | (n > 1 and odd?(n) and t > 9) == tanh(n) + t
>
> would be a "valid" outcome. I wouldn't, however, suggest it, since
> FriCAS allows foo(x | x>0) as input when defining functions, so I am fine if
> the conditional case is shown as it is now.
>
> With the definition
>
> flx x ==> lines(format(format(x::OutputForm)$Formatter(FormatLaTeX)))
>
> we get
>
> (5) -> flx f
>
> ["\SYMBOL{f}\PAREN{\SYMBOL{x}}\ \SYMBOL{==}\
> \FUNCTION{\sin}{\SYMBOL{x}}"]
>
> In other words, the OutputForm cannot be recognized as function, because it
> declares itself just as the juxtaposition of a symbol and a parenthesized
> symbol and not as a function, as it could/should be.

I am not sure what you expect. Clearly output from a formatter needs
parsing to make "logical" sense. And in general we should be working
at higher level, that is preferably with expressions and when needed
with OutputForm.

--
Waldek Hebisch

Ralf Hemmecke

unread,
Jul 3, 2024, 1:31:22 PMJul 3
to fricas...@googlegroups.com
On 7/3/24 18:32, Waldek Hebisch wrote:
> On Wed, Jul 03, 2024 at 05:21:59PM +0200, Ralf Hemmecke wrote:
>> %%% (156) -> h := operator 'h
>>
>> (1) h
>> %%% (2) -> (h(x)::OutputForm pretend SExpression)
>>
>> (2) (h x)

> The above would need seprate fix.

Oh, no, what I meant by this was that the form (h x) it perfect, This is
what I would expect. OK (APPLY h x) would be better, but APPLY does
currently not exist, so I would prefer just (h x).

> But current OutputForm does not have such "logical" operators and
> instead has 'CONCAT' and 'CONCATB'. With limitation of OutputForm
> current output is resonably close to logical form. At least it
> is closer to logical form than output before the change.

Yes.

Ralf
Reply all
Reply to author
Forward
0 new messages