On Sat, Mar 27, 2010 at 11:24 AM, William Stein <[email protected]> wrote: > On Sat, Mar 27, 2010 at 11:14 AM, dabu <[email protected]> wrote: >> Hi, >> >> >> On Mar 27, 12:41 pm, Jason Grout <[email protected]> wrote: >>> On 03/26/2010 11:40 PM, dabu wrote: >>> >>> >>> >>> > Hi, >>> >>> > On Mar 26, 10:00 pm, Minh Nguyen<[email protected]> wrote: >>> >> Hi, >>> >>> >> On Sat, Mar 27, 2010 at 3:47 AM, dabu<[email protected]> wrote: >>> >>> >> <SNIP> >>> >>> >>> It would be somehow more helpful if important sage components like >>> >>> simpy and scipy are compatible by default and one does not have to >>> >>> play with namespaces. >>> >>> >> See PEP 20 for a reason to use namespaces: >>> >>> > The issue is not with namespaces, which is a good programming >>> > practice, but with the incompatibility between simpy and scipy. I >>> > believe some of these important packages should be integrated under >>> > one umbrella. >>> >>> Are you aware that scipy and sympy are two completely separate projects >>> that have little to do with each other? >> Thanks, I am aware of that. the sympy and scipy are different project. >> But I do not agree that they have little to do with each other. >>> It's fine for scipy and for >>> sympy to each import a diff function; the function makes sense in each >>> package's context. I think we would be overstepping our bounds to >>> insist that the scipy folks rename their diff function because some >>> other package out there also had a diff function. >> >> We are not overstepping here , I am sorry if it sounded little off the >> line:) From a user prospective it should be made quite clear what my >> (our) demands are and to see whether it matches with others. For >> example most people who use a CAS system may need some amount of >> numerics and vice versa and something integrated like say Mathematica >> would be much better to an average user. >> >> As it is a free system, it is surely upto the developers to decide how >> much they want subject themselves to user feedback. >> >>> However, if you wanted to pursue this, these questions would be >>> questions for the respective projects (sympy and scipy). For us, a 3rd >>> party integrating both, namespaces is the natural way to access things >>> in each package. >> >> Surely I agree, but somehow sage has a larger user base and these >> packages, that is why I posted here to see what the current status. I >> also very much agree with last statements. Any way I am quite off >> topic now and would not be writing more. >> > > +1 to Pallab's general remarks above (no comment on his specific beefs > with scipy versus sympy semantics). Sage packages scipy and sympy, > but what *MATTERS* at the end of the day is the complete experience we > provide to users. It is certainly our right (as the Sage project) to > change anything we include with Sage, to reshape it, to rethink it, > etc.
Are there some concrete conclusions that we could do in sympy or scipy to make the experience better? I am aware of some sage <-> sympy conversion issues, that I am trying to fix as time permits. Ondrej -- 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/sage-support URL: http://www.sagemath.org To unsubscribe, reply using "remove me" as the subject.
