On Mar 29, 2009, at 7:44 AM, Carl Witty wrote:
>
> On Sun, Mar 29, 2009 at 5:27 AM, Burcin Erocal
> wrote:
>>* We raise an error whenever a function object is specified
>> without
>> variables.
>>
>> Comments?
>
> +1 for raising an error.
+1 for the error here as well.
- Robert
-
Jason Grout wrote:
> David Joyner wrote:
>> On Mon, Mar 30, 2009 at 8:27 AM, Jason Grout
>> wrote:
>>> David Joyner wrote:
No objection. However, I think
sage: t = var("t")
sage: g = function("g",t)
sage: g = sin + t
sage: g(3)
sin(3) + 3
>>> Note that here, you
Jason Grout wrote:
> At the same time, raising an error let's us assign a meaning at a later
> time without worries of backwards compatibility issues.
I'm not convinced. Changing the behavior would require modifying
the symbolic evaluation code, right? It's not something an
ordinary user could c
David Joyner wrote:
> On Mon, Mar 30, 2009 at 8:27 AM, Jason Grout
> wrote:
>> David Joyner wrote:
>
>>> No objection. However, I think
>>>
>>> sage: t = var("t")
>>> sage: g = function("g",t)
>>> sage: g = sin + t
>>> sage: g(3)
>>> sin(3) + 3
>>
>> Note that here, you are redefining g with the
On Mon, Mar 30, 2009 at 8:27 AM, Jason Grout
wrote:
>
> David Joyner wrote:
>>
>> No objection. However, I think
>>
>> sage: t = var("t")
>> sage: g = function("g",t)
>> sage: g = sin + t
>> sage: g(3)
>> sin(3) + 3
>
>
> Note that here, you are redefining g with the functon sin+t (i.e., you
> a
David Joyner wrote:
> On Sun, Mar 29, 2009 at 8:27 AM, Burcin Erocal wrote:
>> Hi again,
>>
>> This is the last in the series of symbolics related emails today. :)
>>
>> I'm looking for comments to trac #5607, which has this summary:
>>
>>
>> In a comment to #5413 Jason pointed out the following
On Sun, Mar 29, 2009 at 8:27 AM, Burcin Erocal wrote:
>
> Hi again,
>
> This is the last in the series of symbolics related emails today. :)
>
> I'm looking for comments to trac #5607, which has this summary:
>
>
> In a comment to #5413 Jason pointed out the following confusing
> behavior:
>
> sa
Robert Dodier wrote:
>
>> * We raise an error whenever a function object is specified without
>> variables.
>
> There's no need to prohibit expressions for which there is not
> yet an interpretation; let the user decide whether something
> makes sense.
At the same time, raising an e
Even I would say that
sage: g(x)=sin
and friends seem a little sketchy. (Though I would point out that
there actually is a sensible default for Sage with such things,
because there is precisely one predefined variable.) But it seems
reasonable to continue to allow unambiguous single-dummy-variab
>(2) I have no idea what "g(x)=sin+x" or "g(x,y)=sin+y" mean anyways.
Perhaps it should mean
g(x) = lambda z: sin(z)+x
h(x,y) = lambda z: sin(z)+y
? So that g(a)(b) == sin(b)+a and h(a,b)(c) == sin(c)+b.
Ralf
--~--~-~--~~~---~--~~
To post to this group, sen
On Sun, Mar 29, 2009 at 5:27 AM, Burcin Erocal wrote:
>
> Hi again,
>
> This is the last in the series of symbolics related emails today. :)
>
> I'm looking for comments to trac #5607, which has this summary:
>
>
> In a comment to #5413 Jason pointed out the following confusing
> behavior:
>
> sa
Burcin Erocal wrote:
> * We could allow this syntax for convenience:
>
> sage: g(x) = sin + x
>
> and convert the function arguments to appropriate callable expressions
> if the number of arguments of g match the number of arguments of the
> given function, raise an error otherwise.
Seems li
g(x):=sin +x
g(3) SHOULD be sin+3.
g(x):=sin
g(3) should be sin
g := sin + identity
g(3)
might possibly be sin(3)+identity(3) or sin(3)+3.
but the use of the syntax g(x) to resolve both lambda-calculus binding
and evaluation as well as operator simplification, resolution of
arguments
On Sun, Mar 29, 2009 at 5:27 AM, Burcin Erocal wrote:
> * We raise an error whenever a function object is specified without
> variables.
>
> Comments?
+1 for raising an error.
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@goo
14 matches
Mail list logo
