axiom-math
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-math] Re: [open-axiom-devel] [fricas-devel] Re: [fricas-devel] Re


From: Ralf Hemmecke
Subject: [Axiom-math] 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.
Date: Mon, 29 Oct 2007 01:53:32 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070728)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]