> So is the following *hypothetical* behavior not possible (or not > desirable)? > > sage: preparse( 'differentiate(y^3, y)' ) > '_ = var("y"); differentiate(y**Integer(3), y)' > > If such a thing were indeed possible, I think it would make simple > uses of Sage for calculus a whole lot easier for students.
+1. And in fact it probably should define y as a variable even if you just do differentiate(y^3). As for the rest: <mild-mannered rant> Following Mma is not always a virtue. One of the many reasons I have never really used Mma and rarely used Maple is because the syntax was simply too convoluted to pick up from the ground level unless I made a big capital investment. Things have gotten better since those days, but still are not ideal. For Sage to compete with Ms, it should have at least some things that are easier to do for entry-level users in unambiguous situations. This is the problem a lot of OSS has had getting used outside certain contexts - I told a graphic designer here about GIMP and that it pretty much does what Photoshop does, but for free and with a much worse user interface, and I think that sort of said it all; her background is software, but none of her staff's is, so enough said. I'm not saying we need a Java, clickable GUI in order to make easy things stay easy (nor am I capable of implementing this), but letting easy things stay easy should remain a goal ("insane ease of use" was David Joyner's phrase long ago in Sage time). In this case, unlike the multivariate context, there is very little ambiguity. Why someone should get an error after doing sage: super_huge_function_with_lots_of_xs_I_need_to_type_accurately_with_lots_of_parentheses_etc.integrate () is unclear to me. Unlike the sage: (x+1)(x+2) x+3 problem, which I can understand as being interpreted as a problem, it seems like this proposal is solving a problem that doesn't exist. The only ambiguity here is for someone doing sage: (y^3).integrate() 3*y^2 who wanted 0 because the variable was x, but such a user would presumably know that the variable of choice makes a difference anyway and would have done sage: (y^3).integrate(y) anyway. Or am I missing something? Maybe something in Pynac would break otherwise? I would be very open to seeing a technical argument for this. And if there is a technical reason it is simpler to require the variable, but no technical reason using the default variable can't be implemented, of course I would be very open to doing some of the work to make this possible. Perhaps this is a moot point for me personally if sage: integrate(x^3) remains functional. I really think it would be silly to require sage: integrate(x^3,x) regardless of what Wolfram or anybody else says. </mild-mannered rant> Notwithstanding all this, a fantastic thank you to Burcin et al. for making sage: f(x)=x^2 sage: f(3) 9 not take 30 seconds! - kcrisman --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---