On Wed, Sep 17, 2008 at 11:50 AM, Waldek Hebisch wrote:
> ...
> Bill Page wrote:
>> Here is a new version of the sumOrParen, productOrParen,
>> powerOrParen and appOrParen that seems to produce a correct
>> result. Note in particular that I moved
>>
>> op = "/" or op = '"/" =>
>> concat(productOrParen(arg1), '"/", powerOrParen(arg2))
>>
>> from sumOrParen to productOrParen.
>
> I had
>
> op = "/" or op = '"/" =>
> concat(appOrParen(arg1), '"/", appOrParen(arg2))
>
> in sumOrParen to force parentheses around arguments of "/" in
> a product. While most parser (including the interpreter parser)
> treat "*" and "/" as having equal priority, some parses give
> them different priority. Exact rules seem to be confusing
> for humans, so I think that extra parentheses here are
> whorthwile.
>
Do you mean confusion over the meaning of expressions like:
a*b/c*d
I suppose some people might incorrectly interpret it as:
(a*b)/(c*d)
but in all computer languages and interpreters I know the result is:
a*(b/c)*d
>> Also I added
>>
>> concat('"(", appOrParen(x), '")")
>>
>> to powerOrParen and removed the special coding for unary minus in appOrParen.
>>
>
> Hmm, have you tried:
>
> unparse(parse("sin(x)^2"))
>
> AFAICS your change will produce extra parentheses here.
>
I just tried it. It does not seem to produce any extra parenthesis.
(11) -> unparse(parse("sin(x)^2"))
(11) "sin(x)^2"
>> SYMBOLP(x) and not(constructor? x) => toString formWrapId x
>> INTEGERP(x) => WRITE_-TO_-STRING x
>> ATOM(x) => form2String0(x)
>> [op, :argl] := x
>> -- Put parenthesis around anything special
>> not(SYMBOLP op) or GET(op, 'LED) or GET(op, 'NUD)_
> ^^^ ^^^
> This is source of the problem, this line should read:
>
> not(SYMBOLP op) or GET(op, "Led") or GET(op, "Nud")_
>
Could you explain a little about what this means?
>> Now I get:
>>
>> (8)
>> "(4*tan(1/2)^2*cos(x+1)*sin(x+1)+((-2*tan(1/2)^3+2*tan(1/2))*cos
>> (x+1)^2+(x*tan(1/2)^4+2*x*tan(1/2)^2+x)))/(tan(1/2)^4+2*tan(1/2)^2+1)"
>>
>> which parses correctly. It seems that this produces the required
>> minimum number of parenthesis.
>>
>
> Without the change above you are still going to get wrong
> results for complicated expressions.
>
Could you give an example?
Regards,
Bill Page.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
