On Tue, May 31, 2022 at 06:56:24AM +0200, Ralf Hemmecke wrote: > On 31.05.22 00:09, Waldek Hebisch wrote: > >On Mon, May 30, 2022 at 08:28:03PM +0200, Ralf Hemmecke wrote: > >>>>I am not so sure what to do for Stream and n<0. > >>>>The result is actually a finite stream, but it would > >>>>mean to expand the input stream up to A just to get > >>>>the first element of the result. Doable, but should > >>>>it be implemented, i.e. who would ever use that? > >>> > >>>I think that for stream error in case of negative increment > >>>is reasonable. > >> > >>In the end it was easier than I thought. > >> > >>The original implementation in LazyStreamAggregate used > >> > >> (not index?(low, x)) or (not index?(high, x)) > >> > >>to check whether the indices are OK. > > > >This looks wrong. > > That is not originally my code. So if you consider it wrong, then it is > wrong even in the current code base.
Yes. > >Evaluating things only when there is demand > >is essential to stream semantics (otherwise recursive constructions > >could fail). To say the truth, several things in LazyStreamAggregate > >could be suspected (but to make progress ATM it is better to focus > >just on 'elt'). > > Can you give a congrete example for your "recursion" argument? When elt(st, > a..b by s) comes into play, st must already be defined whether by recursion > or not. Have you looked how 'seriesSolve' works? It computes coefficient n using earler coefficients. This means that computation of coefficient n is not allowed to look at it or later coefficients. You could argue that using 'elt' and depending on its lazyness (in othere words using some coefficients of stream returned by 'elt' only later) is insane, but clever folks did more strange things. Coming back at 'elt', it produces stream. Lazyness means that if nobody looked at result no elements will be computed. In particular 'elt' should consume no elements if no elements of result are used. More concretly, if you request 'elt(s, 1..10^(10^100))' it should give you a strem. If you then look at 15 elements of resulting stream no more should be computed. To put it differently, only difference between finite and infinite segment should be that when you use all elements of resulting stream in finite case strem should be explicitely empty. Almost all work shoud be done via 'delay'. Of course negative increment is different, in such case we can delay looking at first element (maybe result will be unused ...) but must compute the rest. > If "index?(high, x)" comes into play then the user requests a closed segment > of the stream, so the result will be an explicitly finite stream. This is one of problematic aspect of original code. Apparently it eagerly tries to signal errors. In particular, when elt(s, a..) works, also 'elt(s, a..b)' should work. > >>Since that already expands the stream > >>up to that point, it should not be a problem for negative step sizes. > >> > >>See pull-request. > > > >Using 'maxIndex' will fail for infinite streams. You should > >test with something like: > > > >my_fun(i : Integer) : Integer == i + 1 > >s := stream(my_fun, 1)@Stram(Integer); > > I do not see maxIndex x in the elt implementation in stream.spad, it is only > in ListAggregate. > > And I already tested with an infinite stream in eltuniseg.input. > > https://github.com/hemmecke/fricas/blob/f63c14a4ef45a14fb70988dbd626251c170f3ed3/src/input/eltuniseg.input#L7 Oh, sorry, I missed that. -- 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/20220531142257.GA24356%40fricas.math.uni.wroc.pl.
