[ Stephen, I'm moving the discussion to [EMAIL PROTECTED] as I
believe it raises questions more about the pattern match design choices than
its mere uses. I hope you would be able to follow and contribute there. ]
On Fri, Oct 17, 2008 at 6:04 PM, Stephen Montgomery-Smith
<[EMAIL PROTECTED]> wrote:
> Gabriel Dos Reis wrote:
>>
>> On Thu, Oct 16, 2008 at 4:19 PM, Stephen Montgomery-Smith
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> So the reason I am asking this is so that I persuade axiom to write x^y
>>> as
>>> Pow(x,y) (i.e. make it more C friendly).
>>>
>>>
>>> So I did this:
>>> Pow:=operator 'Pow
>>> powerrule := rule x^y == Pow(x,y)
>>>
>>>
>>> Then I get good results with this:
>>>
>>> powerrule(sqrt(x+y))::InputForm
>>> gives Pow(y + x,1/2)
>>>
>>> But then I was rather surprised at this:
>>>
>>> powerrule(81)
>>> gives Pow(3,Pow(2,2))
>>>
>>> It seems that its attempts to deconstruct '81' are rather aggressive.
>>
>> Pattern matching in OpenAxiom is semantics based, as opposed to being
>> just syntactical. That explains the decomposition of 81. I do not
>> think we have a purely syntactic rewrite system at the moment.
>>
>>> Then I tried this:
>>> Mult:=operator 'Mult
>>> multrule := rule x^y == Mult(x,y)
>>>
>>> The results here are inconsistent:
>>> multrule(6)
>>> gives 6
>>> but
>>> multrule(81)
>>> as I would (now) expect gives Mult(3,Mult(2,2))
>>
>> Hmm, I'm not clear on why the result is inconsistent. As far as I can see
>> 'Pow' was replaced by 'Mult'. Am I overlooking something?
>
> My mistake. I meant
> Mult:=operator 'Mult
> multrule := rule x*y == Mult(x,y)
>
> I would expect
> multrule(6)
> to give the prime factorization, but it doesn't.
You are absolutely right, the behaviour is inconsistent.
I would count that as a bug.
And I'm no longer sure it was a good choice to use
semantics in the pattern matching machinery.
I'm going to explain what is happening -- that does not
necessarily mean that I completely agree with everything
happening.
For Pow, the pattern matcher tries to use a semantics function
to determine a number x that would be raised to some power y
to give 81 -- the system calls perfectNthRoot$IntegerRoots for that task.
That is using the semantics of integers, not just the
syntax of the input (Mathematica which does structural matching
will not succeed in the match).
However, for Mult, no decomposition is done on the input if the
input itself does not suggest the decomposition in the sense that
one of x or y must be an integer constant. Hence the behaviour
your seeing.
There are possible ways to go. One solution would be to disallow
the use of semantics, and stick to structure. That would
consistent with Mathematica, but one would need to assess
the impact on OpenAxiom library itself (I would hope minimal
or none, but hey). If we do that, then there is a question of
what to do with division. Here is an example along what you
showed earlier
Div := operator 'Div
divrule := rule x/y == Div(x,y)
Then divrule(2/3) gives Div(2,3), but divrule(8/2) gives 4.
Again, as you can see here, OpenAxiom is using
semantics to perform pattern matching. It figures
out that 2/3 has type Fraction Integer. However, all
rules insist on operating over Expression Integer, not
Expression T for any T. Consequently, 2/3 is converted
to Expression Integer yielding a pair (numerator,denominator).
Hence the result. For 8/2, the system figures out that
it is actually 4 (using semantics again) and consequenly
the conversion to Expression Integer yields the integer constant,
so the match failed.
The short summary is that, although the Pow case seems
easy to fix (just disallow it), the similar Div case is trickier
because by the time we get into the pattern matcher, the
conversion already happened. On the other hand we cannot
just disallow the Fraction Integer -> Expression Integer
unconditionally in the hope of preventing a ill-advised
conversion for the pattern matcher.
Another option would be to continue with the idea
of using semantics to achieve pattern match. I believe
that is a slipery slope and probably ill-advised.
-- Gaby
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
