On Sun, Oct 29, 2023 at 10:23:23AM +0100, Ralf Hemmecke wrote:
> On 10/29/23 00:00, Waldek Hebisch wrote:
> > Well, is the following "mapping of values"?
> >
> > (1) -> iO := IDPO(Integer, Symbol)
> >
> > (1) IndexedDirectProductObject(Integer,Symbol)
> > Type:
> > Type
> > (2) -> monomial(1, x)$iO
> >
> > (2) [x -> 1]
> > Type:
> > IndexedDirectProductObject(Integer,Symbol)
> > (3) -> monomial(1, x)$iO + monomial(2, y)$iO
> >
> > (3) [y -> 2, x -> 1]
> > Type:
> > IndexedDirectProductObject(Integer,Symbol)
>
> Ah, now I see, what you mean. I agree, that the output looks reasonable,
> however, I somehow think, it is similar to
>
> AL ==> AssociationList(Symbol,Integer)
> RSZ ==> Record(key: Symbol, entry: Integer)
> al := construct([['x1,1]$RSZ,['x2,4]$RSZ,['x3,9]$RSZ])$AL
>
> (11) table(x3 = 9,x2 = 4,x1 = 1)
> Type:
> AssociationList(Symbol,Integer)
Well, at first I expected AssociationList and hash tables to
use the same output as IDPO, but original authors did this differently.
BTW, the following looks strange:
(12) table(1 = 2.0)
Type: AssociationList(Integer,Float)
> Since IDPO represents a finite combination, I still think it should be
> called "...Sum..." instead of "...Product...", but that is another matter.
>
> For IDPO it would also make sense to have
>
> 2*y + 1*x
>
> as output, similar to how divisors are denoted.
IDPO may have extra structure but in general it is just product
with no additional structure. So '*' and '+' are inappropriate
in general case.
> > > > Currently in my test version 'tex.spad' outputs '\rightarrow' and '\to'
> > > > respectively, which seem to be reasonable.
> > >
> > > This is where I do not agree. Why is this reasonable, when TAG actually
> > > denotes the mapping of values? When I denote a function, then I write
> > >
> > > \begin{gather}
> > > f : Z \to Z,\qquad x \mapsto x^2
> > > \end{gather}
> >
> > See above: we give map for each value separately, not a formula
> > for a function. Also "reasonable" does not mean very good,
> > but '\rightarrow' is different symbol than both '\to' and '\mapsto'.
>
> I cannot confirm this on my computer. There
> /usr/share/texlive/texmf-dist/tex/latex/base/fontmath.ltx
> says
> \DeclareMathSymbol{\rightarrow}{\mathrel}{symbols}{"21}
> \DeclareMathSymbol{\to}{\mathrel}{symbols}{"21}
> \DeclareMathSymbol{\mapstochar}{\mathrel}{symbols}{"37}
> \DeclareRobustCommand\mapsto{\mapstochar\rightarrow}
Well, '\rightarrow' is clearly different thing than '\to'. In
default LaTeX setup they just happen to expand to the same thing...
> > There is trouble that '\rightarrow' looks identical to '\to',
> > I thought that they look different. So '\rightarrow' probably
> > should be replaced by differently looking arrow.
>
> Yes. I could live with showing the arrow for IDPO as something different,
> perhaps ":>". Then I would prefer to also show the same notation for all the
> Table domains and ALIST.
Hmm, I would be more happy with "~>" or maybe "=->". Actually,
we can make a lot of different 3 character arrow-like symbols.
If we insist on 2 character symbol, than "~>" is IMO pretty
good one.
> On the other hand, I would not be very happy with ":>", since I would like
> to be able to cut&paste FriCAS output back into FriCAS (at least for
> Format1D). Of course, the latter cannot work by design of OutputForm
> (information is lost). Nevertheless, adding new output arrows that prevent
> cut&paste would be somehow bad.
Well, current OutputForm is quite different than what is accepted
by interpreter. I do not plan significant changes to current
interpreter parser, but adding new operator symbols to old parser
is quite easy. So extra symbols actually can make cut&paste
easier.
<snip>
> Are there opinions of other users/developers?
Lately it was quiet here. I wonder if anybody else is looking
at this.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZT%2BmAkdqgPb8nJoX%40fricas.org.
