On Mar 30, 5:36 pm, William Stein wrote:
> On Mon, Mar 30, 2009 at 8:08 AM, Maurizio wrote:
>
> > I would really like to not have to annoy you with this stuff, but I
> > really think I'm missing something important (and useful!!)
>
> > The first thing I have to say is: how do I check which is
> It sounds like you're talking about the user interface rather than the
> language itself...
Hmm, I guess for someone like me they are quite inter-related, since I
have little programming experience. That seems reasonable. But of
course language is part of the interface, since one has to use i
On Mon, Mar 30, 2009 at 8:43 AM, kcrisman wrote:
>
>> > +1. And in fact it probably should define y as a variable even if you
>> > just do differentiate(y^3).
>>
>> For the record, that will never happen by default in Sage. That goes
>> along with choosing Python as the user language of Sage.
> > +1. And in fact it probably should define y as a variable even if you
> > just do differentiate(y^3).
>
> For the record, that will never happen by default in Sage. That goes
> along with choosing Python as the user language of Sage. Some
> reasons:
>
> 1. Except for ^-->** and int/float wr
On Mon, Mar 30, 2009 at 8:08 AM, Maurizio wrote:
>
> I would really like to not have to annoy you with this stuff, but I
> really think I'm missing something important (and useful!!)
>
> The first thing I have to say is: how do I check which is the type of
> the coefficients (whether they are rat
> >> I really think it would be silly to require
> >> sage: integrate(x^3,x)
>
> > I don't find this so silly, especially in an educational setting. I
> > am forever telling my students that the "dx" part of an integral
> > (definite or indefinite) is not optional. In a definite integral it
> >
I would really like to not have to annoy you with this stuff, but I
really think I'm missing something important (and useful!!)
The first thing I have to say is: how do I check which is the type of
the coefficients (whether they are rationals or something else)? Even
when I do multivariate polyno
On Mon, Mar 30, 2009 at 7:29 AM, Maurizio wrote:
>
> I'm sorry... I wanted to say: is there any plan to make factor()
> working with new symbolic as well? I could see one minute ago that
> expand is already there (although I'm not aware whether is this
> performed through maxima or not, but I don
I'm sorry... I wanted to say: is there any plan to make factor()
working with new symbolic as well? I could see one minute ago that
expand is already there (although I'm not aware whether is this
performed through maxima or not, but I don't think so, since it is a
built-in method for a pynac objec
On Mon, Mar 30, 2009 at 7:19 AM, Maurizio wrote:
>
> One question: is there any plan to replace expand(), factor() and
> other functions like these?
Replace them with what? Do you mean, implement them?
>I don't see them mentioned in the todo,
> and I always find their usage so much time consumi
One question: is there any plan to replace expand(), factor() and
other functions like these? I don't see them mentioned in the todo,
and I always find their usage so much time consuming...
Thanks
Maurizio
On Mar 29, 1:47 pm, Burcin Erocal wrote:
> Hi,
>
> I put up a preliminary todo list for
>> As to the derivative, why not to just use .diff()?
>
> I don't understand the question.
My fault, the new symbolics already uses sin(x).diff(x) to denote
differentiation. I read some of the posts above and I thought for a
while that it uses sin(x).derivative().
>> I don't have an opinion, if
On Sun, Mar 29, 2009 at 7:56 PM, Ondrej Certik wrote:
>
>>> But personally, I find the variants for specifying variables, and
>>> their associated ranges, somewhat confusing. I can never quite
>>> remember if the x is needed or not, and then does it take the form:
>>> x,a,b or (x,a,b)?
>>
>> I
>> But personally, I find the variants for specifying variables, and
>> their associated ranges, somewhat confusing. I can never quite
>> remember if the x is needed or not, and then does it take the form:
>> x,a,b or (x,a,b)?
>
> I now think (x,a,b) should always be *supported*, though it shou
On Sun, Mar 29, 2009 at 6:09 PM, Rob Beezer wrote:
>
> On Mar 29, 5:15 pm, kcrisman wrote:
>> I really think it would be silly to require
>> sage: integrate(x^3,x)
>
> I don't find this so silly, especially in an educational setting. I
> am forever telling my students that the "dx" part of an i
On Mar 29, 5:15 pm, kcrisman wrote:
> I really think it would be silly to require
> sage: integrate(x^3,x)
I don't find this so silly, especially in an educational setting. I
am forever telling my students that the "dx" part of an integral
(definite or indefinite) is not optional. In a definit
On Mar 29, 4:51 pm, William Stein wrote:
> (2) If I write
>
> sage: d = differentiate
>
> would your preparser thing be invoked when I type
>
> sage: d(y^3, y)
>
> If yes, then where do you draw the line? If no, then won't this lead
> to lots of additional confusion?
OK, that makes sense. Ampl
On Sun, Mar 29, 2009 at 5:15 PM, kcrisman wrote:
>
>> 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 ma
> 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 fo
On Sun, Mar 29, 2009 at 4:13 PM, Rob Beezer wrote:
> 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 simp
On Sun, Mar 29, 2009 at 4:13 PM, Rob Beezer wrote:
>
> On Mar 29, 12:29 pm, William Stein wrote:
>> No, it will never ever relieve one of the burden of issuing a var
>> beforehand, since the Python parser can't understand the input
>> expression if the var hasn't been declared.
>
> So, I don't k
On Mar 29, 12:29 pm, William Stein wrote:
> No, it will never ever relieve one of the burden of issuing a var
> beforehand, since the Python parser can't understand the input
> expression if the var hasn't been declared.
So, I don't know much about how the preparser and variables all work,
but t
On Sun, Mar 29, 2009 at 11:33 AM, Rob Beezer wrote:
>
> On Mar 29, 4:47 am, Burcin Erocal wrote:
>> I propose to make the integration variable explicit, by deprecating
>> this use, and encouraging the use of this:
>
> Another +1 for making the variable explicit. Presumably, this will
> also rel
On Mar 29, 4:47 am, Burcin Erocal wrote:
> I propose to make the integration variable explicit, by deprecating
> this use, and encouraging the use of this:
Another +1 for making the variable explicit. Presumably, this will
also relieve one of the burden of issuing a var() beforehand in most
cas
On Sun, Mar 29, 2009 at 6:52 AM, Golam Mortuza Hossain
wrote:
>
> Hi Burcin,
>
> On Sun, Mar 29, 2009 at 8:47 AM, Burcin Erocal wrote:
>> Some time next week, I will put a clean version of the switchover
>> patch, along with a new pynac package and some fixes to the sage
>> library so others can
Hi Burcin,
On Sun, Mar 29, 2009 at 8:47 AM, Burcin Erocal wrote:
> Some time next week, I will put a clean version of the switchover
> patch, along with a new pynac package and some fixes to the sage
> library so others can reproduce the results above.
Great! eager to test them.
> After lookin
26 matches
Mail list logo
