Forgot to add that we would need to include some kind of spreadsheet- like capability, which is quite useful and convenient when one wants to create/edit matrices and arrays.
Hazem On Mar 22, 11:23 pm, Hazem <hazem.biqa...@gmail.com> wrote: > Thank you all for your feedback. > > I agree that maintaining anoher version of Sage is probably spreading > current resources too thin. I was asking to see if this was indeed the > case. On the other hand, an engineering and physics oriented Sage > could help boost Sage and bring in more resources from a largely > untapped and enthusiastic audience. We would be competing more > directly with Mathematica in particular, and other packages (MATLAB, > etc.) in general, and making alot of waves and getting more attention > that way. > > We could start simply by packaging a version of Sage that is smaller > and drops most of the parts that are not widely used by most applied > scientists and engineers, and emphasizes other packages and > capabilities found in MATLAB for example. Documentation would > necessarily have to be written or adapted with applied scientists in > mind, and an aggressive promotion campaign among users of commercial > computation software would be necessary. > > This version of Sage would be based on the main version, but would be > a subset of it for simplicity's sake, more or less, with some optional > packages treated as standard. It would be important not to include > packages that have overlapping functionality, but choose only one of > them. The distribution must be kept relatively small both for size and > to keep it less confusing to a newbie. More integration would come > with time. > > One great "selling" feature would be Cython, which provides the > possibility to achive high computation speeds coupled with a nice and > clean programming language. This is a big consideration for engineers > and applied scientists and it is noteworhy that Python already has a > growing user base among them. With Scilab we can even offer a MATLAB- > like language as an option or as part of a mixed environment. Symbolic > capabilties can be handled by a subset of the packages already offered > (or soon to be offered) by Sage. > > I know what you are going to say: "Hazem, whya don't you do it?" > > I would love to, but honestly my time does not permit, even if I knew > how to do it. I will keep it i mind, though. > > We can advertise for volunteers to take over and run the project, at > least. > > best regards, > > Hazem > > On Mar 22, 9:45 pm, Tim Lahey <tim.la...@gmail.com> wrote: > > > On Mar 22, 2009, at 9:37 PM, Minh Nguyen wrote: > > > > I don't think that maintaining another version of Sage is the way to > > > go at the moment, since many developers have enough on their hands and > > > little time to implement them. What I think is appropriate is to write > > > a Sage interface to your favourite physics/engineering/numerical > > > system, package your interface as an spkg, and announce your spkg on > > > the sage-devel mailing list. A list of current spkg can be found at > > > In my mind, what's generally necessary for engineering purposes is > > a) examples of Sage used for engineering and b) consistency across the > > various interfaces. Right now, one pretty much has to choose if you're > > going to work with polynomials or with symbolics. It would be nice if > > you could take a polynomial you've defined with Pynac, use the fast > > polynomial routines and go back to the Pynac routines for the other > > operations. Plus, there hasn't been a way to do integration with the > > Pynac symbolics. > > > Cheers, > > > Tim. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
