On Thu, Feb 26, 2009 at 9:08 PM, Carl Witty wrote:
> So, should I prepare patches that deprecate implicit calling of
> symbolics and of polynomials? (Would they be likely to be accepted?)
OK, I've posted a patch that deprecates implicit calling of symbolics
(not polynomials) at
http://trac.sage
> Nick Alexander's point about EXPR(x=...) actually being a call is
> another reason to not mention both options. That could presumably be
> fixed with a wording change, but I also have a preference for not
> including a multi-paragraph essay in the warning message :)
If we want short and sweet,
On Fri, Feb 27, 2009 at 10:20 AM, Jason Bandlow wrote:
>
> Carl Witty wrote:
>> On Fri, Feb 27, 2009 at 2:29 AM, Jason Grout
>> wrote:
>>> Can't you put both?
>>>
>>> "Doing substitutions by calling a symbolic expression is deprecated;
>>> use EXPR(x=...,y=...) or EXPR.subs(x=..., y=...) instead
> "Doing substitutions by calling a symbolic expression is deprecated;
> use EXPR(x=...,y=...) or equivalently EXPR.subs(x=..., y=...) instead"
I like the "equivalently", but EXPR(x=...) *is* calling a symbolic
expression -- both EXPR(1) and EXPR(x=1) go through the __call__
method. This is
Carl Witty wrote:
> On Fri, Feb 27, 2009 at 2:29 AM, Jason Grout
> wrote:
>> Can't you put both?
>>
>> "Doing substitutions by calling a symbolic expression is deprecated;
>> use EXPR(x=...,y=...) or EXPR.subs(x=..., y=...) instead"
>>
>> Or
>>
>> "Function evaluation of symbolic expressions with
On Fri, Feb 27, 2009 at 2:29 AM, Jason Grout
wrote:
> Can't you put both?
>
> "Doing substitutions by calling a symbolic expression is deprecated;
> use EXPR(x=...,y=...) or EXPR.subs(x=..., y=...) instead"
>
> Or
>
> "Function evaluation of symbolic expressions without specifying
> variables is
Jason's argument is interesting. I'll think about that one; if good
math and good programming go together, it should probably be done.
Anyway, the decision is made.
But I'm not sure that x(x+1) being x+1 is as much of a problem; does x
(x+1) have any meaning in the current Sage framework other t
arl Witty wrote:
> On Thu, Feb 26, 2009 at 9:24 PM, William Stein wrote:
>> On Thu, Feb 26, 2009 at 9:08 PM, Carl Witty wrote:
>>> So, should I prepare patches that deprecate implicit calling of
>>> symbolics and of polynomials? (Would they be likely to be accepted?)
>> Definitely for symbolics
Dear all,
I am so glad to hear that the implicit substitutions are going to go! It
is so much clearer to write e.g.
var('a b c x')
f = a*x^2 + b*x + c
f(x=4,a=1,b=3,c=2)
rather than
f(1,3,2,4)
to get the desired result. Most people I know got burned with implicit
assumptions in Fortran unti
On Thu, Feb 26, 2009 at 9:24 PM, William Stein wrote:
>
> On Thu, Feb 26, 2009 at 9:08 PM, Carl Witty wrote:
>> So, should I prepare patches that deprecate implicit calling of
>> symbolics and of polynomials? (Would they be likely to be accepted?)
>
> Definitely for symbolics. I'm less clear a
On Feb 26, 2009, at 9:08 PM, Carl Witty wrote:
>
> On Thu, Feb 26, 2009 at 8:55 PM, William Stein
> wrote:
>> Just out of curiosity, do you think we should also get rid of this?
>>
>> sage: R. = ZZ[]
>> sage: x(x+1)
>> x + 1
>
> Ouch, that's a tougher question, since I actually use that
> co
On Thu, Feb 26, 2009 at 9:08 PM, Carl Witty wrote:
>
> On Thu, Feb 26, 2009 at 8:55 PM, William Stein wrote:
>> Just out of curiosity, do you think we should also get rid of this?
>>
>> sage: R. = ZZ[]
>> sage: x(x+1)
>> x + 1
>
> Ouch, that's a tougher question, since I actually use that constr
On Thu, Feb 26, 2009 at 8:55 PM, William Stein wrote:
> Just out of curiosity, do you think we should also get rid of this?
>
> sage: R. = ZZ[]
> sage: x(x+1)
> x + 1
Ouch, that's a tougher question, since I actually use that construct :)
But since I don't want to be a total hypocrite, I'm goin
+1
On Feb 26, 9:05 pm, Jason Grout wrote:
> Carl Witty wrote:
> >> Anyway, as several have commented, this discussion has taken place
> >> many times before, but having to use
> >> sage: f(x)=x^2
> >> instead of
> >> sage: f=x^2
> >> many times for single-variable symbolic expressions could be v
Carl Witty wrote:
>> Anyway, as several have commented, this discussion has taken place
>> many times before, but having to use
>> sage: f(x)=x^2
>> instead of
>> sage: f=x^2
>> many times for single-variable symbolic expressions could be very
>> annoying in the long run, IMHO. Let's not be stul
On Thu, Feb 26, 2009 at 8:38 PM, Carl Witty wrote:
>
> On Thu, Feb 26, 2009 at 8:06 PM, kcrisman wrote:
>>
>>> Consider this:
>>> sage: E = (x+3)*sin(x)
>>> sage: E(5)
>>> 8*sin(5)
>>> sage: E.subs(x=5)
>>> 8*sin(5)
>>>
>>> So E(5) is treated as a shorthand for E.subs(x=5).
>>>
>>> Now if we con
On Thu, Feb 26, 2009 at 8:06 PM, kcrisman wrote:
>
>> Consider this:
>> sage: E = (x+3)*sin(x)
>> sage: E(5)
>> 8*sin(5)
>> sage: E.subs(x=5)
>> 8*sin(5)
>>
>> So E(5) is treated as a shorthand for E.subs(x=5).
>>
>> Now if we consider:
>> sage: var('f x')
>> (f, x)
>> sage: f(x+3)
>> x + 3
>> sa
> Consider this:
> sage: E = (x+3)*sin(x)
> sage: E(5)
> 8*sin(5)
> sage: E.subs(x=5)
> 8*sin(5)
>
> So E(5) is treated as a shorthand for E.subs(x=5).
>
> Now if we consider:
> sage: var('f x')
> (f, x)
> sage: f(x+3)
> x + 3
> sage: f.subs(f=x+3)
> x + 3
>
> it's the exact same thing.
>
> This c
The discussion of "lisp 1" vs "lisp 2" designs periodically occurs in
the comp.lang.lisp
newsgroup, and may be the subject of a FAQ. The Scheme dialect of lisp
is a lisp 1.
Common Lisp is a lisp 2.
The question revolves around the issue of whether there is are
separate namespaces for functions an
On Feb 26, 2009, at 2:54 PM, Mike Hansen wrote:
> On Thu, Feb 26, 2009 at 2:52 PM, YannLC
> wrote:
>>
>> Thanks for the explanation.
>> I definitely don't like this shortcut:
>>
>> sage: var('foo bar')
>> (foo, bar)
>> sage: E = foo+bar
>> sage: E(5)
>> foo + 5
>>
>> why not "bar +5" ?
>>
>> b
On Thu, Feb 26, 2009 at 2:52 PM, YannLC wrote:
>
> Thanks for the explanation.
> I definitely don't like this shortcut:
>
> sage: var('foo bar')
> (foo, bar)
> sage: E = foo+bar
> sage: E(5)
> foo + 5
>
> why not "bar +5" ?
>
> but I'll learn to live with it :)
It goes by alphabetical order by d
Thanks for the explanation.
I definitely don't like this shortcut:
sage: var('foo bar')
(foo, bar)
sage: E = foo+bar
sage: E(5)
foo + 5
why not "bar +5" ?
but I'll learn to live with it :)
Yann
On Feb 26, 11:42 pm, Carl Witty wrote:
> On Thu, Feb 26, 2009 at 2:35 PM, Robert Bradshaw
On Thu, Feb 26, 2009 at 2:35 PM, Robert Bradshaw
wrote:
>
> On Feb 26, 2009, at 2:28 PM, YannLC wrote:
>
>> Forgive my stubborness, but you answered only half of my question :)
>> do you think the following is a sane behavior?
>>
>> sage: var('f x')
>> (f, x)
>> sage: f(x+3)
>> x+3
>>
>> I would
On Feb 26, 2009, at 2:28 PM, YannLC wrote:
> Forgive my stubborness, but you answered only half of my question :)
> do you think the following is a sane behavior?
>
> sage: var('f x')
> (f, x)
> sage: f(x+3)
> x+3
>
> I would prefer a NotImplementedError...
This has come up many times, and it's
Forgive my stubborness, but you answered only half of my question :)
do you think the following is a sane behavior?
sage: var('f x')
(f, x)
sage: f(x+3)
x+3
I would prefer a NotImplementedError...
Yann
On Feb 26, 11:14 pm, Robert Bradshaw
wrote:
> On Feb 26, 2009, at 1:15 PM, YannLC w
On Feb 26, 2009, at 1:15 PM, YannLC wrote:
> On Feb 26, 9:40 pm, Robert Bradshaw
> wrote:
>> On Feb 26, 2009, at 12:22 PM, YannLC wrote:
>>
>>> Hi,
>>> am I doing something wrong here?
>>> If not, this is a bug...
>>
>>> sage: f=function('f',x)
>>> sage: f
>>> f(x)
>>> sage: g(f,x)=f(x+1)
>>> sa
On Feb 26, 9:40 pm, Robert Bradshaw
wrote:
> On Feb 26, 2009, at 12:22 PM, YannLC wrote:
>
> > Hi,
> > am I doing something wrong here?
> > If not, this is a bug...
>
> > sage: f=function('f',x)
> > sage: f
> > f(x)
> > sage: g(f,x)=f(x+1)
> > sage: g
> > (f, x) |--> x + 1
>
> When one writes g
On Feb 26, 2009, at 12:22 PM, YannLC wrote:
> Hi,
> am I doing something wrong here?
> If not, this is a bug...
>
> sage: f=function('f',x)
> sage: f
> f(x)
> sage: g(f,x)=f(x+1)
> sage: g
> (f, x) |--> x + 1
When one writes g(f, x) it creates two variables f and x, and your
original f is gone
28 matches
Mail list logo
