Re: [open-axiom-devel] [fricas-devel] Re: [fricas-devel] Re: [fricas-devel] Re: [fricas-devel] Re: [fricas-devel] Re: [fricas-devel] Re: iterators and cartesian product.

Ralf Hemmecke <[email protected]> Mon, 29 Oct 2007 01:53:32 +0100
Newsgroups gmane.comp.mathematics.axiom.general
Message-ID <[email protected]>
On 10/28/2007 10:37 PM, Bill Page wrote:
 > On 10/27/07, Ralf Hemmecke wrote:
 >> Let me cite the documentation from stream.spad.pamphlet
 >>
 >> ++ A stream is an implementation of an infinite sequence using ++ a
 >> list of terms that have been computed and a function closure ++ to
 >> compute additional terms when needed.
 >>
 >> First, a stream is an infinite sequence. If we get
 >>
 >> (6) -> s:=construct([1,2,3])$Stream(Integer) (6) -> (6)  [1,2,3]
 >> Type: Stream Integer (7) -> s.4 7) ->
 >>>> Error detected within library code:
 >> elt: no such element
 >>
 >> Then there is either something wrong with the code or with the
 >> documentation.

 > I think it is the documentation. Given the exports of Stream, it
 > obviously should say only "potentially infinite".


Hmmm, I think, now we can start fighting. ;-)

I would be in favour of letting Stream(T) encode the


   T^N

where N is the natural numbers.
It seems that you want Stream(T) to denote

   T^N union T^(N)

where the second thing denotes the set of finite sequences (which is
actually already modelled by List or Array).

I have nothing against a domain that models the above union, but I would
like to start with basic domains and then build on them. And I would
reserve the name "Stream" for the infinite thing.

 >>> The larger question remains however: When to use a domain to
 >>> directly model something that is "set-like" and when to define a
 >>> higher-order domain whose objects are "set-like"? To me this is
 >>> not clear in either Spad or Aldor.
 >> I don't think you gain very much if you only consider set-like
 >> domains. If, however, you are looking at finite fields, for sure,
 >> you will think of a domain, since it is more important that there
 >> are some operations that connect the elements.

 > So you say it is natural to define "PrimeField 7" as a domain itself
 > rather than defining a general domain of "PrimeFields" and
 > constructing "PrimeField 7" as an element of that domain?

Honestly, I don't see much of a difference. In your and my view
"PrimeField 7" is a domain, which exports certain functions.
Nobody forbids me to create a domain whose elements are domains. (Maybe
SPAD does forbid...) But I think "PrimeFields" is a rather uninteresting
domain. What exports should it have?

 > Yes, I think that makes sense. But there are of course some
 > operations that connect elements of any well defined set, no?

Which? (Sorry, but I really cannot think of one.)

 > I suppose what I am saying is that (maybe) there should really be no
 > distinction between domains and members of domains (objects) - that
 > all objects should also be domains in and of themselves.

Let's go on with your thoughts. Could you tell me what operation the 
integer 2 (considered as a domain) should export?

Ralf