Re: [Axiom-developer] Re: [#358 Variable is apparently always assumed to be positive?]Functions and Segments

[Bill Page]

On 6/11/07, William Sit wrote:
> Bill Page wrote:
> >
> > Thanks for adding your comments to the wiki. I have
> > re-arranged this a little by separating the comments about
> > segment from those about functions so that now your
> > comments about segments appears here:
> >
> > http://wiki.axiom-developer.org/SandBoxFloatSegment
>
> I wonder why you did not move it to a separate IssueTracker?
> It is bug in the implementation of 'expand' (incompatibility
> with 'BY').

If you mean the interpretation of BY in terms of "counting" that is
implied by the description then I think that would be incompatible
with the intention of the original question, but of course it is plausible
and I agree that it is inconsistent with the implementation of expand.
Please feel free to submit such an issue report if you like. Giving a
new meaning to BY as I did in my modified Segment would then
be one possible resolution of this issue (which also happens to
satisfy the original question.)

> ...
> I made some comments on your construction, see
> http://wiki.axiom-developer.org/SandBoxFloatSegment

Thanks!

> > Can you imagine an actual application where it is interesting
> > to define a segment over something that is not a Ring?
>
> I gave a simple example of MWF as a segment of M..S by 2.

But  ZMOD 7 has Ring, so what you wrote can be cast in this
form naturually. :-) We can define this segment but we cannot
expand it as a list since it does not have OrderedRing. But
since it does have Finite, we could resort to a simple test for
equality in such cases so I agree the OrderedRing is probably
too strong a requirement.

> In general, one can define a segment in any chain (linearly
> ordered set) ..

Yes, I agree. Thanks for the explanation. So in this case we must
have

 Segment(S:OrderedSet)

In which case a Segment would have to be something represented
by Record(low:S and high:S) only, no 'incr' since there may not be
any 1 or 'nextItem' in S. For example it does not make any sense
to define Segment Float by only considering every other point.

> The 'BY' construction  (expansion by adding) may not be that
> meaningful in this context (the meaning of "add" is usually
> missing), although it certainly make sense to do expansion
> by counting.

I am not sure. I think that in Axiomatic terms it might be necessary
that the domain also be a member of the category STEP, i.e. where
'nextItem' is defined but I do not see any apriori reason why 'nextItem'
need respect some fixed total ordering.

> That is why there should be two 'BY' constructs. Unfortunately,
> putting them in the same package would cause confusion when
> the parameter of SEGMENT is Integer.

I am more inclined to think that the original definition given to BY
was just a little ill conceived.

Regards,
Bill Page.