On Fri, Jun 10, 2022 at 08:19:17AM +0200, Ralf Hemmecke wrote:
> Just a short answer to clarify and come closer to a design decision.
>
> >>In this case I can immediately say that any access to the stream will be an
> >>error. So the guideline is "error as early as possible, but no expanding of
> >>the stream is forbidden until a value is needed.
> >
> >I would delete 'no' from what you wrote, otherwise I do not know
> >what it means.
>
> Of course. "no" should go away.
>
> >I would write "error on access. but not earler".
>
> That somehow is in contradiction to the general principle "error as early as
> possible".
>
> >And 'st(-3..0)' does not count as access.
>
> Yes, I agree. But it does not mean, that an implementation cannot find out
> that any access to the resulting stream will be an error.
>
> >>t := st(-4..1)
>
> Same here.
>
> >>I would still say, there should be an
> >>immediate error for two reasons
> >>A) In a stream to get t(6) the previous entries should have been
> >> computed. (Admittedly a questionable reason.)
> >
> >Yes. 't(6)' should give error. Computing earlier entries is _very_
> >fundamental for streams.
> >
> >>B) (-4..1) clearly does not fall into the source domain in the sense of
> >> "streams are considered as functions from {1,2,..,n} of from all
> >> positive integers to the coefficients.
> >>
> >>Case B is the actual reason why I would want an immediate error.
> >
> >You mean 'st(-4..1)' is computed?
>
> No. I mean that to compute the resulting stream, no element of st is ever
> evaluated. But from the -4 bound, the implementation can find out, that the
> resulting stream will give an error.
>
> Now, of course, it is a design decision whether we say, that if a user
> computes st(-4..1) then that should give an immediate error or whether it is
> allowed to create such a stream without error, but any access to it would
> lead to an error.
>
> I see your point that lazyness overrules everything even to create a stream
> that leads to error on any evaluation. Oh, I just wanted to give this
> example ...
>
> (1) -> f(): Integer == error "no element"
> Function declaration f : () -> Integer has been added to workspace.
> Type: Void
> (2) -> st: Stream Integer := stream(f)
> Compiling function f with type () -> Integer
>
>
> Error signalled from user code in function f:
> no element
>
> Either I do something wrong or the implementation of the "stream" function
> is not truely lazy.
For printing interpreter forces evaluation of first few elements
of the stream. Without printing I get:
1) -> f(): Integer == error "no element"
Function declaration f : () -> Integer has been added to workspace.
Type: Void
(2) -> st: Stream Integer := stream(f);
Compiling function f with type () -> Integer
Type: Stream(Integer)
(3) -> st(1)
Error signalled from user code in function f:
no element
> If you want st(-4..1) to give no error, then stream(f) should also be OK and
> only stream(f).1 should signal an error.
As you see above.
> My opinion was/is that st(-4..1) can be figured out immediately to give a
> "bad" stream, so signal an error. stream(f) should give no error, since
> creation of stream forbids evaluation and the current implementation is
> actually wrong.
>
> I can agree with "lazyness overrules early error", but then it should be
> consistent in all of the implementation of Stream and is must be clearly
> stated in the docstring of Stream or even of LazyStreamAggregate (as design
> decision).
Yes, I proposed adding to LazyStreamAggregate:
++ Elements of LazyStreamAggregate are computed only when strictly
++ needed. Lazy computation means that potential errors are
++ delayed, so errors are detected later than in case of normal
++ (eager) evaluation used by other aggregates. In some cases
++ computation that would signal error when using eager evaluation
++ can succeed when using lazy evaluation.
--
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/20220610105031.GA30366%40fricas.math.uni.wroc.pl.
