On May 7, 2010, at 3:47 PM, Sebastian wrote:
> 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.
I think it is impossible to use the order of the keywords anyway, because
Python puts them in a dictionary, which is unordered.
The order argument seems like it could be simpler (too much typing!). Plus, it
is redundant, because you are giving the hints twice. Therefore, I think the
best solution is to have something like Chris suggested, where you can give the
hints all together and it takes the order from that, so just
expand(trig_multinomial=True), or expand(hints=("trig", "multinomial") should
be enough. And if you don't care about order, then expand(trig=True,
multinomial=True) should be fine (just make it clear in the docstring that this
will necessarily be unordered).
Another possibility would be to somehow take advantage of *args, which is
ordered.
Aaron Meurer
>
>>>
>>>> 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.
>
--
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.
