Changes
http://wiki.axiom-developer.org/358VariableIsApparentlyAlwaysAssumedToBePositive/diff
--
++added:
+
+From wyscc Thu Jun 7 05:03:55 -0400 2007
+From: wyscc
+Date: Thu, 07 Jun 2007 05:03:55 -0400
+Subject: Functions and Segments
+Message-ID: <[EMAIL PROTECTED]>
+
+billpage wrote::
+
+ Anonymous wrote::
+
+ Axiom is "stupid" to even think that in the definition
+ of h, the x is symbolic
+
+ In Axiom x, 1, and 1.0 are all equally symbolic. The distinction
+ between "symbolic" and "numeric" is not relevant.
+
+I think anonymous' view is correct: a function is just a rule that assigns a
+value when given a value. The 'h' defined earlier (a function prototype as you
+call it) can only be interpreted with a source domain that has an order, a
+multiplication, and a negation. However, if 'x' is interpreted as a FIXED
+element in 'POLY INT', 'h' is no longer a function from 'POLY INT' to 'POLY
INT'
+(unless you view 'h' as defining the substitution homomorphism on $Q[x]$
sending
+$x$ to $-x^2$; but that is not what we meant when we want to integrate 'h').
As
+far as calculus goes, we integrate a function, NOT a polynomial $h(x)$ with a
+FIXED indeterminate $x$ although by abuse of notation, we use the polynomial
+$h(x)$ to mean the function itself. Thus for Axiom to test $x < 0$ with $x$ as
a
+FIXED interminate in $Q[x]$ in a function (or function prototype) definition
+is unwise no matter what context; x must be interpreted as a dummy variable
+(place holder) only.
+
+$[\dots]$
+
+Let's examine Segment S::
+
+ So this is how it works by design, but I think it would be quite easy to
+ define a new type of segment that has the properties that you expect.
+
+The function 'BY' is specified in 'SEGCAT' as::
+
+ [1] (D,Integer) -> D from D if D has SEGCAT D2 and D2 has TYPE and
+ SEGCAT D2 exports
+ BY: (%, Integer) -> %
+ ++ \spad{s by n} creates a new segment in which only every \spad{n}-th
+ ++ element is used.
+
+and 'SEGCAT' exports::
+
+ ------------------------------- Operations --------------------------------
+ BY : (%,Integer) -> % ?..? : (S,S) -> %
+ convert : S -> % hi : % -> S
+ high : % -> S incr : % -> Integer
+ lo : % -> S low : % -> S
+ segment : (S,S) -> %
+
+In fact, 'BY' does not do anything other than record the 'low', 'high' and
'incr' of
+the segment and there is no requirement on 'S' (I think to define any segment,
+'S' should be at least a lattice (without 'BY') and a linearly ordered set
(with
+'BY'))::
+
+ Rep := Record(low: S, high: S, incr: Integer)
+ BY(s, r) == [lo s, hi s, r]
+
+The current implementation of 'BY' is incorrect (the bug is obvious once
+exposed, since 'BY' does not do anything other than to update the
+representation; it should of course *do* some computation!)
+
+\begin{axiom}
+a:=2..10 by 2
+expand a
+b:= a by 4
+expand b
+c:=(2..10 by 2) by 3
+expand c
+\end{axiom}
+
+The answer for 'b' and 'c' are both wrong. Note that the signature of 'BY'
allows
+iterated use, and one should have the mathematical equality::
+
+ (a..b by c) by d = a..b by c*d (multiplication in Integer)
+
+So 'b' should be '2..10 by 8' and 'c' should be '2..10 by 6'.
+
+This can be fixed as::
+
+ BY(s,r)==(lo s, hi s, r*incr(s))
+
+Ah, but there is more!
+
+Since 'BY' does not actually enumerate, expansion into a list is done
+externally from 'SEGCAT', is specified by 'SEGXCAT', but unfortunately, is
+*inconsistent* with 'BY' ::
+
+ SegmentExpansionCategory(S: OrderedRing, L: StreamAggregate(S)).
+ expand: % -> L
+ ++ expand(l..h by k) creates value of type L with elements
+ ++ \spad{l, l+k, ... lN} where \spad{lN <= h < lN+k}.
+ ++ For example, \spad{expand(1..5 by 2) = [1,3,5]}.
+
+Using this specification, expand a should be $[2,4,6,8,10]$. However, it is
+not clear what 'c' should return since '(2..10 by 2)' is not expanded; if it
+were (note '(expand a) by 3' would have syntax error, but 'expand(a by 3)'
would
+not), expanding 'c' should cause an error since 'low + incr = 2+3=5' is not in
+the expanded segment $[2,4,6,8,10]$ for 'a'. As it is, it seems one may
+interpret 'c' as '(2..10 by 5)', where '5' is the sum of the two incr's, and
*when*
+expanded, $[2,7]$. Of course, neither is consistent with the definition of
+'BY', which simply *counts* and *does not add*. I am not sure about the design
+principle behind leaving a segment unexpanded. As we shall see, this seems
+to cause more confusion when 'BY' is generalized and iterated.::
+
+ SegmentExpansionCategory(S: OrderedRing, L: StreamAggregate(S)).
+
+To require an 'OrderedRing' for 'expand' is overkill, to imply possibly using
+multiplication by integer instead of iterated addition by 'incr' is promoting
+inefficiency, and to require that 'incr' must be an 'Integer' is plainly
wrong.
+There is no requirement that 'S' includes the 'Integer' as a subring (even
+though one can embed 'Integer' into a domain of characteristic zero; clearly,
+a strongly typed system like Axiom would not allow adding apples to oranges
+without coercion). But even if 'Integer' is a subring, the restriction is
+unjustifiable. Since 'Float' has 'OrderedRing', this unreasonable insistance
on
+'incr:Integer' *a priori* requires any numerical algorithm (such as
Runge-Kutta
+methods for differential equations or Newton's method for solving an
+equation) that wants to iterate through an incremental step to manually
+translate a float segment to an integer segment and back.
+
+In my opinion, there should be two versions of 'BY' (and corresponding
+'expand'):
+
+<ul>
+<li> one 'expand' (with 'incr:Integer') marches through 'low' to 'high' every
'incr'
+item in the segment 'low..high' in any linearly ordered set (for example, one
+should be able to iterate through 'MWF' in 'MTWTFS' using 'M..S by 2'); call
this
+*expansion by counting*
+
+<li> the other 'expand' (with 'incr:S', where 'S' is an
'OrderedAbelianMonoid'),
+marches through 'low' to 'high', incrementing by 'incr' (via addition in 'S')
until
+just before out of bound; call this *expansion by adding*
+</ul>
+
+Note that even when 'S' contains (or is) 'Integer', the two segment
+constructions and 'expand' may be different depending on where the second
+argument of 'BY' comes from: 'Integer' or 'S' (for example::
+
+ (2..10 by 2::Integer) by 4::Integer %% =[2, 10] (after expansion by
counting)
+
+is not the same as::
+
+ (2..10 by 2::S) by 4::S %% = [2,8] (after expansion by adding)
+
+The compiler would require the author to distinguish the two 'BY' 's, but the
+interpreter may have difficulty if domains are not given. We also need some
+rules to simplify iterated 'BY' 's and there are four cases and we need a new
+representation of segments. As a first attempt to deal with the two "pure"
+cases, we may try::
+
+ Record[low:S, high:S, incr:Union(Integer, S)]
+ BY: (%, Union(Integer, S)) -> %
+ BY(s,r) ==
+ r case Integer and incr(s) case Integer =>
+ [low s, high s, [EMAIL PROTECTED]
+ r case S and incr(s) case S =>
+ [low s, high s, r+s]$Rep %%one interpretation
+
+But these are "pure" compositions of the same 'BY' 's. Moreover, by combining
+the two types in one construct, we raise the requirement on 'S' when we may
+only need expansion by counting in an application. If a segment is
+constructed by iterated mixed 'BY' 's, that requirement would be okay. But it
+seems we then have to interpret intermediate segments in the expanded sense
+(which might not be compatible with the previous composition using two
+similar "pure" ways). So we have a dilemma. We may finesse the issue if we
+separately implement two types of segments and do not allow them to mix.
+That would be the simplest route.
+
+On the other hand if we want to allow mixed segment constructions, we may
+need a recursive data structure to represent segments::
+
+ baserep:= Record[low:S, high:S, incr:Union(Integer, S)]
+ Rep:=Record[baserep, incr:Union(Integer, S)]
+
+The implementation of 'expand' would be more complicated.
+
+William
+
--
forwarded from http://wiki.axiom-developer.org/[EMAIL PROTECTED]
