Hello,
I am pretty sure I am wrong but why not something like:
)abbrev domain RHSUP RHSparseUnivariatePolynomial
RHSparseUnivariatePolynomial(R) : Exports == Implementation where
R : Ring
Exports ==> UnivariatePolynomialCategory(R) with
foo : () -> String
Implementation ==> SparseUnivariatePolynomial(R) add
foo() == "foo"
coerce(p : %) : OutputForm ==
h := p pretend SparseUnivariatePolynomial(R)
outputForm(h, "t"::Symbol::OutputForm)
)abbrev domain RH2SUP RH2SparseUnivariatePolynomial
RH2SparseUnivariatePolynomial(R) : Exports == Implementation where
R : Ring
Exports ==> UnivariatePolynomialCategory(R) with
foo : () -> String
bar : () -> String
Implementation ==> SparseUnivariatePolynomial(R) add
foo() == "foo"
bar() == "bar"
coerce(p : %) : OutputForm ==
h := p pretend SparseUnivariatePolynomial(R)
outputForm(h, "t"::Symbol::OutputForm)
)abbrev package RHX RHx
RHx(R: Ring, POL : UnivariatePolynomialCategory(R)): with
var: () -> OutputForm
if POL has foo : () -> String then
foo : () -> String
if POL has bar : () -> String then
bar : () -> String
bar2 : () -> String
== add
mon ==> monomial$POL
if POL has foo : () -> String then
foo() == foo()$POL
if POL has bar : () -> String then
bar() == bar()$POL
bar2() == bar()$POL
var(): OutputForm == mon(1$R,1$NonNegativeInteger) :: OutputForm
?
- Greg
PS: I will respond to your question later in another thread about SUP,
SingletonAsOrderedSet etc when I can, sorry.
Le jeu. 3 juil. 2025 à 17:44, Waldek Hebisch <[email protected]> a écrit :
>
> On Thu, Jul 03, 2025 at 07:46:22AM +0200, 'Ralf Hemmecke' via FriCAS -
> computer algebra system wrote:
> > On 7/3/25 03:15, Waldek Hebisch wrote:
> > > You are exploring land of bugs.
> >
> > As usual. ;-)
> >
> > I don't even know whether such a construction is specified to work even in
> > Aldor.
>
> I would say that from general point of view code looks OK.
> It is just question what in implemented in the respective compiler.
>
> > The following compiles
> > >
> > > )abbrev package RHX RHx
> > > RHx(R: Ring, POL: R -> UnivariatePolynomialCategory R): with
> > > var: () -> OutputForm
> > > == add
> > > fT := POL(R)
> > > mon ==> monomial$fT
> > > var(): OutputForm == mon(1$R, 1$NonNegativeInteger)::OutputForm
> > >
> > > but generated code is wrong.
> > >
> > > In general, your code here is quite different than current algebra
> > > code. That is normally caller would evaluate POL(R) nad RHx would
> > > use its value.
> >
> > Hmmm... but that seems to tell my that I would have to make a part of the
> > respective (RHx) package explicit to the caller.
> >
> > Actually, I oversimplified. What I really want inside RHx is calling
> > functions from POL(Matrix R), i.e., I should have given
> >
> > RHx(R: Ring, POL: (X:Ring) -> UnivariatePolynomialCategory X): with
> >
> > as the initial line of definition. In my current setup the respective POL
> > constructor would even have a second parameter that depends on X.
> > I wanted to hide the (respective) "Matrix" constructur from the caller as
> > implementation detail.
>
> You need to specify them somewhere. Old Spad way it to pass all
> such thing down trough intermediate constructors. Some things
> may be hidden by using categores: category specifies what needs
> to be visible to users of a package, package may have more arguments
> or more specific arguments. You may look at amodgcd.spad.
> ModularAlgebraicGcdOperations specifies things in terms of abstrat
> types and users of packages of this category only see abstrat
> things, but unneeded specifics are hidden. Only package gets
> full details.
>
> Also, there is question of efficiency. Your 'var' is probably
> rather uncritical, but in amodgcd.spad I wanted as efficient code
> as possible. Giving specific types to packages (and in fact
> "hardcoding" some details inside packages) lead to efficient
> code inside. With code as you wrote there is ususaly expensive
> call to package/domain that is specified only at runtime. My
> modification above which compiles moved place where POL(R) is
> fully specified to place that is run only once (that is at
> package instationation time). Theoretically Spad compiler could
> automatically do such transformantions, but I do not think
> that this is done now.
>
> There is related issue. To get better efficiency Spad compiler
> normally caches types, that is types is instantiated once and
> reused after that. But if type depends on runtime values, then
> it must be dully recomputed. Spad functions may produce different
> value on each call, even if arguments are the same, so your
> use disallows caching. My modification explicitely caches type
> value.
>
> One extra remark: I do not know how to implement such calls
> efficiently. This means that usually I would prefer different
> construct. This limits my motivation to implement them
> (which currently seem to require substantial work).
>
> --
> 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 visit
> https://groups.google.com/d/msgid/fricas-devel/aGalT4ix9bI3JAKm%40fricas.org.
--
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 visit
https://groups.google.com/d/msgid/fricas-devel/CAHnU2dYUtNr9_BD21wX6SdmH4E6UPbyD-XWBbnyX6L8Pf7FCOA%40mail.gmail.com.
