On Thu, Jun 09, 2022 at 05:27:46PM +0200, Ralf Hemmecke wrote:
> >AFAICS the expected results are OK.   However, the various tests
> >are quite repetitive.
> 
> Well, they are. It seems, you want them in just one file.
> OK, I can reorganize them.
> 
> >In stream case TESTLIBRARYERROR(A, B) probably should
> >expand to testLibraryError(entries complete x(" A ")"), that
> >is force computation.
> 
> I do not quite understand. If x is an infinite stream and I call for entries
> complete x(2..), then the test will run forever.

Well:
 - AFAICS streams that you test that way are finite
 - without access to offending entry there should be no error and
   access should be lazy so to get error we should force access

> For infinite streams I wanted to test for an immediate error, because either
> the stepsize is 0

OK

> or we know from the segment that eventually it will hit a
> point below minIndex of the stream, i.e. < 1.

This error should be only after actual access.  Without access                  
we do not know if there will be error.

> >Also, for better coverage we probably should have test like
> >this:
> >
> >    s := ...;
> >    testEquals("s(3)", "42")
> >    testLibrarryError("s(4)")
> >
> >(this may require low enough setting for 'stream calculate').
> 
> Adding such a testcase explicitly says that it is OK to apply a segment that
> eventually leads to an "error" index as long as the user does not hit such
> an index. I am not so sure whether I would (via explicit testcase) build it
> into the specification.

Well, without access in general you can not know if there is an error.
And our code depends on lazy evaluation.  That includes code working
when all accessed elements are valid.  So regardless of oficial
specification code will depend on this.  Given that there will be
dependency I think it is better to test that it works.

> I would rather like to leave it open so a user
> cannot rely to say x(a..bignumber) and then expect he gets the "intersection
> of indices"-semantics. Clearly, x(a..bignumber) is actually an error if x is
> finite and maxIndex(x)<bignumber. That we not immediatly return that error
> but only when an index after maxIndex(x) is asked for, is an implementation
> detail, but not something that I would like to specify.

Let me repeat of what I wrote: x(a..bignumber) on infinite stream
is valid way of saying "give me error if computation does not
finish before arriving at bignumber".  OTOH stream computations
that access only k first elements are supposed to work on finite
stram of length k.  Special casing finite streams would only
plant bugs.  Leaving this unspecified is almost like saying
that finite streams and 'elt' with finite range are second class
citizens, fine when you want to produce list but probably not fit
to work as real 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/20220609172837.GC14512%40fricas.math.uni.wroc.pl.

Reply via email to