On Jul 15, 2009, at 4:58 AM, smichr wrote:
> > > > On Jul 13, 3:30 am, "Aaron S. Meurer" <[email protected]> wrote: >> think that powsimp() could benefit from this? When I rewrote it >> several weeks ago, I added a switch "combine" to control the two >> different combining methods (see the docstring for more info). So >> basically, you can do combine='exp' to only combine exponentials, >> combine='base' to only combine bases, and combine='all' (the default) >> to do both. I think we could probably use your function to do >> exp=True and base=True. Also, I think my dsolve hints function >> that I > > or you could add the option 'power' which does both base and exp. > > >> Maybe you should also add a default_dict=True that takes in a >> dictionary of default options, incase there is a function that uses >> **kwargs instead of default arguments. > > I hardly use these sorts of things so I would have to defer to those > with more experience. > >> It would also allow default >> options to be False instead of True, though I don't know how much >> that >> would complicate the rules that you have outlined below. > > You have the option in the switch manager of giving it a default of > False; maybe I am misunderstanding what you mean. > >> >> On the two lines below, I assume you mean "if one or more switches >> have been set to True and none are set to False". It is a little >> ambiguous the way you have it. > > Yes, I could have said "If all given switches are True then the rest > will be set to False and if all given are False then those that have > not been given will be set to True." >> >>> -if one or more switches have been set to True then set the rest >>> to False; >>> -if one or more switches have been set to False then set the rest >>> to True. >>> """ > > One thing I was thinking about along the lines of "explicit is better > than implicit" is that this becomes a little more implicit in terms of > what is on and what is off and a clear method of indicating switches > logic is important. e.g. in the docstring we might put something like: > > Hint options: > - basic > - log > - mul > - multinomial > - power_exp > - power_base > F complex > F func > F trig > > key: > (-) indicates options to select as being True or False and those that > are unselected will have the opposite sense (e.g. if log=True then > ONLY log will be True) > (F) indicates options that are off unless explicitly set to True (i.e. > expand(log=False) will only turn on the (-) hints, not the (F) hints. > > Something like that...one issue that isn't resolved for me is how to > handle the (F) args: if you do expand(func=True) should that turn all > the (-) ones off? The way the routine works right now, those that are > not in the (F) set do not affect the (-) set. I guess to only use the > func expansion you would have to do: expand(default=off, func=True) > This is what I was talking about with complications with default False arguments. I think having an additional default argument would work, like you describe. Aaron Meurer > Open to ideas, > /c > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" 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/sympy?hl=en -~----------~----~----~----~------~----~------~--~---
