direct function argument vs variable

[Ralf Hemmecke]

I have tried the following code.

S ==> UnivariateLaurentSeries(Fraction Integer, 'x, 0)
sx := x :: S
s := (sx^3-7*sx)/(3*sx^7-sx^4)
terms s
TERMS n == [r for r in terms(s) while r.k < n]
ll := TERMS 4
entries ll
entries TERMS 4

Interestingly the last three evaluations show as:

(6) -> ll := TERMS 4
Compiling function TERMS with type PositiveInteger -> Stream(Record(
k: Integer,c: Fraction(Integer)))

(6)
[[k = - 3, c = 7], [k = - 1, c = - 1], [k = 0, c = 21], [k = 2, c = - 3],
[k = 3, c = 63]]

Type: Stream(Record(k: Integer,c:
Fraction(Integer)))
(7) -> entries ll

(7)
[[k = - 3, c = 7], [k = - 1, c = - 1], [k = 0, c = 21], [k = 2, c = - 3],
[k = 3, c = 63]]

Type: List(Record(k: Integer,c:
Fraction(Integer)))
(8) -> entries TERMS 4

>> Error detected within library code:
infinite stream

I am not afraid of the actual error, because in general that must be
expected, but storing a value in a variable seems to make a difference
for the interpreter. I'm not sure that an ordinary user likes or
understands this.

In fact, I don't understand why the "entries" function would get another
argument value if called this or that way. What is happening here?

Ralf

[Waldek Hebisch]

It is printing, not storing in variable. Compare:

ll := TERMS(4);
entries(ll)

entries(complete(TERMS(4)))

Printing have to compute few first terms of a stream. Entries
(and in general functions defined for finite aggreagates) works
only if all terms are already computed.

Also look at:

numberOfComputedEntries(TERMS(4))
explicitlyFinite?(TERMS(4))
numberOfComputedEntries(complete(TERMS(4)))
explicitlyFinite?(complete(TERMS(4)))
numberOfComputedEntries(ll)
explicitlyFinite?(ll)

--
Waldek Hebisch