On 05/07/2010 11:31 PM, Aaron S. Meurer wrote:
> On May 7, 2010, at 2:44 PM, Sebastian wrote:
>
>
>> On 05/07/2010 02:57 PM, smichr wrote:
>>
>>>> Of Chris's stuff, I like some of the shortcuts he has implemented that
>>>> reduce typing for more complex hints. Sebastian's writeup doesn't mention
>>>> some of the key things, like the logic for what turns other hints on and
>>>> off (I am assuming this would all go in the HintManager).
>>>>
>>>>
>>> I can quickly elaborate on the hint manager's features:
>>>
>>> keyword expansion (mult=True -> multinomial=True)
>>>
>>>
>> This might be convenient for quick hacks, but code might break as soon
>> as new keywords are introduced. Also this really does not enhance
>> readability. I think it's okay to define keywords as abbreviations but I
>> don't like this general expanding.
>>
>>
>>> keyword validation (multy=True could generate an error; bas=True is
>>> ambiguous and generates an error)
>>>
>>>
>> +1 for validation.
>>
>>
>>> keyword concatenation (mul_multinomial=True)
>>>
>>>
>> I don't think this is much of an improvement. Of course code gets a
>> little bit shorter but you also loose the underscore for hints.
>>
>>
>>> keyword ordering when concatenated; otherwise ordering is as given in
>>> the stored hints
>>>
>>>
>> Why would order be important if you set all the concatenated hints to
>> the same value? I think order of hints really shouldn't change the
>> behavior of code.
>>
> For expand(), it can matter. For example, sin((x+y)**2).expand(trig=True,
> multinomial=True) will come out different depending on if you do the
> multinomial expansion first, or the trig expansion first (because the trig
> expansion only works when the args are an Add). See also the docstring of
> expand().
>
> Another illustrative example is log((x + 1)*(y + 1)). If you expand the Mul
> first, you can't expand the log; if you expand the log first, you can't
> expand the Mul.
>
Right, thanks for the explanation. Would an order argument be an
acceptable alternative? E.g. something like:
expr.expand(trig=True, multinomial=True, order=("trig", "multinomial"))
I really think the order of the keywords themselves should not be used
for any decisions. If you had for example two keywords which are
sensitive to order and you want to give them different values then you
are out of luck.
>>
>>> customizable default keyword (e.g. all=True can set all hints to True)
>>>
>>>
>> +1 for having hints that trigger default values for other hints. But
>> maybe to set all keywords at once to the same value might not for all
>> cases where hints are needed be a good choice.
>>
> I agree. Right now, the hints for expand are hard to use, because you have
> to turn off the hints you don't want. It would be much easier and future
> proof to new hints to just have expand(mul=True) turn off everything else
> (the general gist of Chris's manager is to do this, I think).
>
>>
>>> After doing this, I wonder if the keyword manager for running scripts
>>> might be enlisted to handle some of this...I never looked into it,
>>> however.
>>>
>>>
>>>
>> Sorry, what keyword manager do you mean?
>>
> I'm guessing the OptionParser.
>
> Aaron Meurer
>
>> Sebastian
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sy...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
