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.
I have not exactly studied seriesSolve, but at the time I implemented
Aldor-Combinat (with Martin Rubey), I had a similar problem when
defining Species by a polynomial (which ended up defining the underlying
powerseries in a recursive fashion just as you describe above).
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.
Well, here I simply followed what the original code gave me.
Unfortunately, there is no documentation telling me what intent the
original developers had with their code.
I can perfectly agree with the carma saying "no evaluation of a
coefficient until its explicit value is needed".
More concretly, if you request 'elt(s, 1..10^(10^100))' it should
give you a strem.
See, I thought about that. Suppose you have l := [1,2] and you want
elt(l,1..bignumber), then you immediately get an error, because l is too
short and it is clear that bignumber > maxIndex(l).
Now suppose that s = l::Stream(Integer) and you ask for
elt(s,1..bignumber), then everything will work fine unless you come to
access s(3).
Well, one could say, everything is fine, because I only need a short
part of the stream. On the other hand s(1..bignumber) is actually a
series that eventually runs into a definite error. Now the question is,
whether we want that. Obviously, the original developers decided against
that inherent error and thus tried to check the indices at creation time
of the datastructure.
I can understand both views.
OK a hard error is anyway a dead end for a computation once it is hit.
The question here is only when it should occur either at creation time
of the elt or later at accessing a non-existing value.
I am only worried about the problem of finding the programming mistake
when the error actually occurs.
If SPAD had proper exception handling, I would be even more worried.
Anyway, if you want a truely lazy elt, I can, of course change my code
accordingly. (Of course, if a user asks for t:=elt(stream, 10.. by -1),
I could add a delay and access stream.10 only when t.1 is actually asked
for.
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.
Oh... the semantics of elt(s, a..) is "give the part of stream s that
starts at position a". Semantics of "elt(s, a..b)" is give (b-a+1)
(consecutive) elements from stream s starting at position a". For a
fintite stream elt(s,a..) will give a proper stream starting from a (up
to the end of the stream of s is finite). That is OK as long as
a<=maxIndex(s). Or we could even claim that the resulting stream will be
empty if a>maxIndex(s). What should it be?
elt(s, a..b) must give an error of a or b are bigger than maxIndex(x)
(maybe a delayed error as discussed above).
Ralf
--
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/2933e347-bc22-9308-3e15-53508161212a%40hemmecke.org.
