On Tue, May 31, 2022 at 08:13:43PM +0200, Ralf Hemmecke wrote:
>
> >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.
My guess is that they simply did not give enough thougt to 'elt'.
They were inventing things and were busy enough with "core"
functionality. Old wisdom says "only one who does not make
mistakes, is the person who does not do anything".
> 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.
Desire to detect error early is natural. But IMO for streams it is
misguided. Namely, important part of lazyness is that deferred
computation may contain error. In particular, deferred computation
may be created first and only later code may decide that result
is is not needed, thus avoiding error.
> 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?
I think that proper semantics for 'elt(s, 1..b)' is "truncate the
stream after element number b". This is report empty after delivering
b elements. If orignal stream ends earlier we should report empty
earlier. Of course, if code tries to fetch element anyway, than
this is an error. However, empty condition should be detectable.
To put it differently, 'elt(s, a..b by c)' with positive c should be
like 'select' with appropriate predicate, except for that predicate
in 'select' can not see indices. Actually, it would be nice to implement
'elt' and 'select' as part of the same functionality. Unfortunatly,
there is no way to ensure that predicate in 'select' is called
in order and only once per element so trying to use 'select'
to implement 'elt' would fail.
> elt(s, a..b) must give an error of a or b are bigger than maxIndex(x) (maybe
> a delayed error as discussed above).
AFAICS error should come from accessing empty stream.
--
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/20220531194334.GA28547%40fricas.math.uni.wroc.pl.
