Hi Françaois,
I'm changing the 'Subject:' as the issue you raised is not about the
case pattern construct.
Francois Maltey <[EMAIL PROTECTED]> writes:
| Hi Gabriel,
| > As an illustration, take the package ToolsForSign. It contains the
| > following definition for `sign'.
| >
| > if R has RetractableTo Fraction Integer then
| > sign r ==
| > (u := retractIfCan(r)@Union(Fraction Integer, "failed"))
| > case Fraction(Integer) => sign(u::Fraction Integer)
| > nonQsign r
| > else
| > if R has RetractableTo Integer then
| > sign r ==
| > (u := retractIfCan(r)@Union(Integer, "failed"))
| > case "failed" => "failed"
| > sign(u::Integer)
| >
| > -- ...
| >
| > This the usual form of dealing with retractIfCan(), and I think it
| > looks gastly (well, my opinion).
| >
| And what is the nonQsign call ? I don't understand where this function
| is defined.
I did not show it but it is another function defined by the package
ToolsForSign.
| This category ToolsForSign avoids to recode this sign function in all
| domains. Am I right ?
ToolsForSign is a package, and indeed is supplies general definitions
for sign.
| And suppose there is a better sign function in this domain.
| The definition of this function sign remains inside this domain.
| Must we suppress the declaration of the category ToolsForSign in this
| domain ? Or [EMAIL PROTECTED] overload [EMAIL PROTECTED]
If you have a domain D that exports a 'sign' function and you say
sign e
where e is an expression of type D, then the name lookup rules are
such that the `sign' function in D will be selected.
|
| May we remplace nonQsign by [EMAIL PROTECTED] ?
| An other case where such domain may be useful : In all polynomial
| domains we often test if the polynom is constant (in R) or integer or
| monic.
Hmm, there is no construct for [EMAIL PROTECTED] You can
approximate that by structural testing for sign, e.g.
D has sign: % -> ...
but I would think, it might be more appropriate to investigate the
possibility defining a category for those domains foe which it makes
sense to talk about 'sign' (therefore exports a `sign' operation).
|
| May be possible to have a category with functions which detect any
| p*a+q*b where p and q are integer for all polynomial domains.
Hmm, I don't understand this suggestion. Could you clarify?
|
| By example expand in expressions must operate over sin (3*a+2*b)
| and the 2 and 3 coefficients don't depend of the domain
| polynomial. Today axiom code uses only Polynomial domain and it's
| impossible to adapt expression to DistributedPolynomial for this
| reason (and others)
|
| And, last question, is there a such way to get in Expression the
| %i=sqrt(-1) : or does the code remain :
|
| if R has imaginary : R -> R
| then use innerI := imaginary()::Expression R
| else use innerI := sqrt(-1::R)
|
| rewrite rules for exp (an i * a) = cos (a) + thisI * sin (a)
I suspect that one why probably want to revisit some design decision
about Expression and the fact that `rules' are hardwired by the parser
to operate on Expression Integer.
-- Gaby
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
