[fricas-devel] [PATCH] cleanup sturm.spad; replace subresultantSequence with subresultantVector

subresultantSequence has a few problems, so I replace subresultantSequence(p,q) with subresultantVector(p,q). Note that, degree(p)>degree(q) is always ture in the changed part. And it used to use only last degree(q) elements, now it uses first degree(q) elementes. -- You received this message

Re: [fricas-devel] should =$List check for cyclic list

A grep shows that there are only 23 setrest! used in algebra code (non data structure code). I suspect that none of them will create a cyclic list. (I'll look into it). If so, we may make List non-cyclic by default, and add a new domain that is cyclic. > To put it differently: it seems that

Re: [fricas-devel] should =$List check for cyclic list

oldk1331 wrote: > > I think the correct way is to have 2 domains for lists: > one potentially with cycle, one guaranteed to not have cycle. > Adding checks in setrest! should be enough to prevent > the creation of cyclic lists. Such check would have to travel to the end of added part to be

Re: [fricas-devel] Heap exhausted during garbage collection 1.3.0

oldk1331 wrote: > > BTW, the profile data is from SBCL profiler, right? Yes. > PS, we can add a "heuristicIntegrate", which tries varies > human tricks to do integration, and keep "integrate" algorithmic. Well 'heuristic' really mean "algortihm that we do not understand". In case of

Re: [fricas-devel] should =$List check for cyclic list

> Looking at IndexedList I see that 'copy' signals error on cyclic > lists. It makes some sense as allowing 'copy' to run would exhaust > memory and lead to crash. This probably motivates quite > small value for 'cycleMax'. But if function just sits in > infinite loop there not little problem:

Re: [fricas-devel] Heap exhausted during garbage collection 1.3.0

oldk1331 wrote: > > > You mean we should have more special cases? In general > > I am trying to have as little special cases as possible. > > > So possibly instead of seeking special > > cases we should use modular methods. > > In this case, modular methods might be a good solution; > but in

Re: [fricas-devel] Heap exhausted during garbage collection 1.3.0

BTW, the profile data is from SBCL profiler, right? PS, we can add a "heuristicIntegrate", which tries varies human tricks to do integration, and keep "integrate" algorithmic. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.

Re: [fricas-devel] Heap exhausted during garbage collection 1.3.0

> You mean we should have more special cases? In general > I am trying to have as little special cases as possible. > So possibly instead of seeking special > cases we should use modular methods. In this case, modular methods might be a good solution; but in general case, integrate(c*f(x),x) =

Re: [fricas-devel] Heap exhausted during garbage collection 1.3.0

oldk1331 wrote: > > > Yes. I am not sure how big is result of extendedEuclidean, > > It is not big. I computed it by resultantEuclidean in 50s, > (semiResultantEuclidean2 in 30s). You mean for the extendedEuclidean in integrate((f^2 + x^2)/((x - a)* (x - b)* (x - c)* (x - d)), x) > > -

[fricas-devel] [PATCH] some doc and typo fixes

Here's some doc and typo fixes I found recently. -- 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+unsubscr...@googlegroups.com.

[fricas-devel] should =$List check for cyclic list

= from URAGG checks for cyclic structure, while = from List doesn't do this check. Is it for performance? I think this is a bug. diff --git a/src/algebra/list.spad b/src/algebra/list.spad index 2c92001c..b228f395 100644 --- a/src/algebra/list.spad +++ b/src/algebra/list.spad @@ -116,7 +116,8 @@

Re: [fricas-devel] parts, members, entries

On Sun, Mar 5, 2017 at 10:22 AM, Waldek Hebisch wrote: > As long as aggregate imposes order 'parts' should do: > construct(parts(x)) shoud be x, so 'parts' should > preserver whatever order aggregate has. Of course, > if aggregate is unordered like Set, then 'parts' >

Re: [fricas-devel] parts, members, entries

oldk1331 wrote: > > OK, so there's a documentation bug in parts/members. > And "entries" is available for aggregates which isn't > a finiteAggregate. All of them don't guarantee order. > > What I want is a function that returns its elements to a > list in order, so that I can convert/compare >

[fricas-devel] [PATCH] RCAGG: fix document; add 'leaves' for RCAGG/List/Stream

"leaves" is not implemented for List/Stream, I add a default one in RCAGG. There's also a version for List that checks for loop and a version for Stream that checks for infinity and loop. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra

Re: [fricas-devel] parts, members, entries

OK, so there's a documentation bug in parts/members. And "entries" is available for aggregates which isn't a finiteAggregate. All of them don't guarantee order. What I want is a function that returns its elements to a list in order, so that I can convert/compare IndexedVector/IndexedList etc. to

Re: [fricas-devel] parts, members, entries

On 03/04/2017 09:51 PM, Waldek Hebisch wrote: >> I think these 3 functions are the same. > (1) -> s := multiset [1, 2, 3, 2, 3, 3, 3] > >(1) {1,2: 2,4: 3} > Type: Multiset(PositiveInteger) > (2) -> parts(s) > >(2) [1,2,2,3,3,3,3] >

Re: [fricas-devel] Re: parts, members, entries

Martin R wrote: > > It would make sense to have one function that produces a list l such that > "construct(l)@domain" produces the original thing. For Collection 'parts' gives such list: parts : % -> List S ++ parts(u) returns a list of the consecutive elements of u. ++

Re: [fricas-devel] parts, members, entries

> > I think these 3 functions are the same. (1) -> s := multiset [1, 2, 3, 2, 3, 3, 3] (1) {1,2: 2,4: 3} Type: Multiset(PositiveInteger) (2) -> parts(s) (2) [1,2,2,3,3,3,3] Type:

Re: [fricas-devel] 1.3.1 tag on GitHub mirror

On 03/04/2017 12:35 PM, oldk1331 wrote: > Ralf, could you update the GitHub mirror to include tag 1.3.1? Sorry for the omission. It's pushed now. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from

[fricas-devel] Re: parts, members, entries

It would make sense to have one function that produces a list l such that "construct(l)@domain" produces the original thing. Martin -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop

[fricas-devel] 1.3.1 tag on GitHub mirror

Ralf, could you update the GitHub mirror to include tag 1.3.1? -- 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] parts, members, entries

I think these 3 functions are the same. >From HOAGG, parts and members have the same documentation: "returns a list of the consecutive elements of u." "consecutive" doesn't imply "order". >From IXAGG, entries "returns a list of all the entries of aggregate u in no assumed order." So all of