> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to