The function leadingTerm with signature hashcode is missing from domain UnivariatePuiseuxSeries

[Tobias Neumann]

EI ==> Expression(Integer)

ups := UnivariatePuiseuxSeries(EI,'t,0)

leadingTerm(monomial(1, 1/2)$ups)$ups

   Internal Error

   The function leadingTerm with signature hashcode is missing from

      domain UnivariatePuiseuxSeries(Expression (Integer))t((0 . 0) 0 . 1)

It seems like this is just missing implementation in the series expansion domains, just like `leadingSupport`, unless I'm overlooking something.

Tobias

[Kurt Pagani]

ups inherits from IndexedProductCategory(A, S)
leadingTerm: % -> Record(k: S, c: A) if S has Comparable

leadingTerm(x) returns the leading (with respect to the ordering on the
indexing set) term of z. Error: if z has no support.

EI has Comparable -> true, but I guess there is no support in IPC.

At least this works:

(2) -> terms(monomial(1, 1/2)$ups)$ups

1
(2) [[k = -, c = 1]]
2
Type: Stream(Record(k: Fraction(Integer),c: Expression(Integer)))



(3) -> leadingMonomial(monomial(1, 1/2)$ups)$ups

1
-
2
(3) t
Type: UnivariatePuiseuxSeries(Expression(Integer),t,0)



(3) -> terms leadingMonomial(monomial(1, 1/2)$ups)$ups

1
(3) [[k = -, c = 1]]
2
Type: Stream(Record(k: Fraction(Integer),c: Expression(Integer)))


thus

leadingTerm x ==> terms leadingMonomial x


(5) -> leadingTerm(monomial(1, 1/2)$ups)

1
(5) [[k = -, c = 1]]
2
Type: Stream(Record(k: Fraction(Integer),c: Expression(Integer)))

may be a work-around.

> --
> 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 fricas-devel...@googlegroups.com
> <mailto:fricas-devel...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fricas-devel/5d0d8f66-47ae-453d-b1fd-43946b0f6a9en%40googlegroups.com
> <https://groups.google.com/d/msgid/fricas-devel/5d0d8f66-47ae-453d-b1fd-43946b0f6a9en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ralf Hemmecke]

Hi Tobias,

If you refer to
https://github.com/fricas/fricas/issues/54
then yes, you are right. I did not have time to come up with a patch
when I reported this bug.

So feel free to add that function at the right place. It shouldn't be
too hard. But you probably should cover all series domains. Not only
Taylor or Puiseux series.

There is a generic implementation here

https://github.com/fricas/fricas/blob/master/src/algebra/indexedp.spad#L233

but that does not apply, since IndexedDirectProductObject has finite
support. Actually a strange name, should be IndexedDirectSumObject if
the support is supposed to be finite.

Ralf

[Tobias Neumann]

If you refer to
https://github.com/fricas/fricas/issues/54
then yes, you are right. I did not have time to come up with a patch
when I reported this bug.

Woops, what a coincidence that you reported that today already. Should have looked on github before.

 

So feel free to add that function at the right place. It shouldn't be
too hard. But you probably should cover all series domains. Not only
Taylor or Puiseux series.

It probably makes sense to implement this in UnivariatePowerSeriesCategory (upscat.spad)

where also leadingMonomial etc. from IndexedProductCategory are defined. This could be done

using something like Kurt suggested. That avoids multiple implementations in the series domains

(where one could use the Rep). I'll think about it. 

Best wishes,

Tobias

[Tobias Neumann]

So feel free to add that function at the right place. It shouldn't be
too hard. But you probably should cover all series domains. Not only
Taylor or Puiseux series.

It probably makes sense to implement this in UnivariatePowerSeriesCategory (upscat.spad)

where also leadingMonomial etc. from IndexedProductCategory are defined. This could be done

using something like Kurt suggested. That avoids multiple implementations in the series domains

(where one could use the Rep). I'll think about it. 

 

 For example, adding these to UnivariatePowerSeriesCategory does the job:

    leadingTerm f == terms(leadingMonomial(f))(1)

    leadingSupport f == leadingTerm(f).k

I think we can safely assume that there is always a first element,

unless the series is 0, in which case `order` as used in leadingMonomial fails in first place.

Tobias

 

[Waldek Hebisch]

In general I try to implement all officially declared functions.
However, in case of series domains it is not clear if we should
add fake implementations (as done for several other functions)
or remove problematic signatures.

Basically tradeoffs are:
- "proper" algoritms dealing with series will use things
like two argument 'order' and only extract terms of
specified order
- nor-series algoritms sometimes work for series, but to use
them we need fakes (fake '=', one argument 'order', etc..).

It is tempting to add more fakes to series domains, to make
it easier to use series in naive way. OTOH, Boot code in
'src/interp' nicely shows mess that appears when naive
approach is continued too long. Missing signatures give
reasonably early warning about potential problems. Fakes
delay problem, which may be good enough for immediate
need (if algorthm using fakes finishes without trouble),
but are essebtially debt to be payed in the future:
moving forward we will have either to carefully validate
involved code or possibly discard it.

Important part in programming, particularly for series
is finding good patterns. Current series patterns do
not need 'leadingTerm'. So it is not clear for me
if we really need it.

BTW: Of course the fundamental problem is zero series. In
few rare cases we can recognize explicit zero series. But
otherwise code dealing with series must be aware of possibility
of zero series. Namely, a lot of classical (non-series)
algorithms produce zeros at various intermediate steps.
Such zeros need proper handling, otherwise algorithm
applied to series will fail from time to time.

BTW2: Alternatively to leaving them undefined we could
define them like this:

leadingTerm(s) == error "Do not use leadingTerm for series"

or maybe:

leadingTerm(s) == error "leadingTerm: not supported for series"

This is generic implementation that could be added to appropriate
category.

--
Waldek Hebisch

[Tobias Neumann]

BTW2: Alternatively to leaving them undefined we could
define them like this:

leadingTerm(s) == error "Do not use leadingTerm for series"

or maybe:

leadingTerm(s) == error "leadingTerm: not supported for series"

This is generic implementation that could be added to appropriate
category.

I see the issues. As a new user I also stumbled upon the caveats that lazy infinite series bring. But

when you're aware of these issues, these functions can still be useful, after taking the necessary precautions.

I agree that there should be consistency and I see some possibilities to address that:

1. Have all functions that are not guaranteed to terminate throw an error (your BTW2). This means

if users want to have such functionality, they will have to implement it themselves.

2. Implement everything, and put big fat warnings in the documentation for these functions.

3. Implement some helper package/domain that implements these functions? Or force users to set some flag

so that they can use these functions "set this flag if you know what you do".

After some thought I'd probably go for option 2.

I don't know if there is some example for this in the manual, but one could just have some section

about this in the manual, where the non-terminating functions are listed, and have an example that

they are easily generated, for example like: order(series(exp(x),x=0) - series(exp(x),x=0))

I think also the web API could be improved. For example when I started using FriCAS I didn't realize that 

a lot of functions have descriptions, but only when it track them back to the category where

they are defined. So on https://fricas.github.io/api/UnivariatePuiseuxSeries.html you don't see that

order can run into problems, only on https://fricas.github.io/api/UnivariatePowerSeriesCategory.html

Other functions like leadingMonomial don't have such warnings at all.

I very much would like to have/keep these functions in some way in the official version,

so that I don't have to reimplement them.

I believe that if this was better documented, I would not have had such issues. So I'm opting for implementing

everything and improving the documentation together with it.

[Kurt Pagani]

> I think also the web API could be improved. For example when I started using
> FriCAS I didn't realize that 
> a lot of functions have descriptions, but only when it track them back to the
> category where
> they are defined. So
> on https://fricas.github.io/api/UnivariatePuiseuxSeries.html you don't see that
> order can run into problems, only
> on https://fricas.github.io/api/UnivariatePowerSeriesCategory.html
> Other functions like leadingMonomial don't have such warnings at all.
>

A ")show ups" reveals that it is not pretended having leadingTerm being
available. So the API is IMO not generally binding in the sense that the
parameters have yet to be determined. I rely on ")show XY", i.e. when the type
is complete (as you surely noticed there may be a lot of "if X has Y" in the
sources).