On 09.06.22 19:28, Waldek Hebisch wrote:
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
Ah... now I understand. You want to make sure that the implementation
truely returns a finite stream and not suddently something else.
But if I use entries(complete result) then I access every possible
entry, that excludes the an infinite result. By calling "entries" I get
a list. What else can I want then requiring that this list is equal to
an expected list? There is no need for testing "out of range" errors.
I wouldn't even know how to implement a stream that expands to the right
list and additionally has an index (bigger than the maxIndex) so that
x(index) does NOT give an error.
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.
st: Stream Integer := [k for k in 1..]
st(-3..0)
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.
t := st(-4..1)
t(6)
That virtually corresponds to st(1). 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.)
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.
To be honest, I do not yet know whether I actually can implement it that
way, since I first have to test for immediate errors and only then can
start a delay structure.
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.
You mean there might be somewhere some code in our repo that uses
s:=x(u) already and we should not break it now? I doubt but I will not
fight for a removal of the
testEquals("s(3)", "42")
line in a testsuite.
Given that there will be
dependency I think it is better to test that it works.
If you think so. OK.
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".
If x is infinite then there is no error. If x is a stream that may
perhaps be finite (we just do not yet know, then x(n) for n < bignumber
should of course return an error. If you mean the above in that sense,
then I agree completely that access to elements should be valid as long
as they are computable.
OK. We agree.
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/d4185518-fc10-35dd-976b-7676e6f67359%40hemmecke.org.
