On 9/27/07, Fernando Perez wrote:
>
> On 9/27/07, Robert Bradshaw wrote:
>
> > I agree with your caution, but don't see how the examples above mess
> > anything up. If an object B wants to pretend to be immutable, it
> > merely has to check that nothing points to it before mutating itself
> > (and
On 9/27/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> I agree with your caution, but don't see how the examples above mess
> anything up. If an object B wants to pretend to be immutable, it
> merely has to check that nothing points to it before mutating itself
> (and, in mutating itself, don't
Well, I don't want to take the thread off topic, but in the standard
(documented) way of creating new operators, it is done with an
assignment to MakeExpression. This will work in a notebook, where
boxes are transformed into expressions before execution, but it will
not work in a .m file, because
On Sep 27, 2007, at 2:47 PM, Fernando Perez wrote:
> The problematic issue is that some extensions (numpy first and
> foremost, but this buffer API is going into the core of the language
> for 2.6/3.0) allow multiple, distinct *python objects* to share the
> same (or parts of the same) chunk of r
Robert Miller wrote:
>> The best I've come up with at this point is, given graphs A,B,C,D,E, the
>> union is:
>>
>> A.union(B).union(C).union(D).union(E)
>>
>> where the union function returns the modified graph each time so I can
>> keep chaining union function calls. The union actually modifies
On 9/27/07, Fernando Perez wrote:
> ...
> In [12]: a = N.arange(10)
>
> In [13]: sys.getrefcount(a)
> Out[13]: 2
>
> Here the refcount is 2, as expected: the original array and the name
> 'a' pointing to it.
>
> Now, a naked, unassigned slice of the original array has a refcount of 1:
>
> In [14]:
On 9/27/07, Bill Page <[EMAIL PROTECTED]> wrote:
>
> On 9/27/07, Fernando Perez wrote:
> >
> > On 9/27/07, Robert Bradshaw wrote:
> >
> > > You have a good point, though fortunately we're looking for refcounts
> > > so low that (essentially) nothing else can be holding onto it but the
> > > curren
On 9/27/07, Fernando Perez wrote:
>
> On 9/27/07, Robert Bradshaw wrote:
>
> > You have a good point, though fortunately we're looking for refcounts
> > so low that (essentially) nothing else can be holding onto it but the
> > current stack frame. If b is pointing to a, it doesn't matter how
> > m
> The best I've come up with at this point is, given graphs A,B,C,D,E, the
> union is:
>
> A.union(B).union(C).union(D).union(E)
>
> where the union function returns the modified graph each time so I can
> keep chaining union function calls. The union actually modifies the
> graph A, so if you wa
On Sep 27, 2007, at 1:45 PM, Jason Grout wrote:
> Robert Bradshaw wrote:
>> On Sep 27, 2007, at 4:43 AM, Jason Grout wrote:
>
>>> A=A.union(B)
>>>
>>> to modify A?
>>
>> Yes. Or even
>>
>> A.inplace_union(B)
>>
>> (or some better name than that) which returns nothing. Otherwise, for
>> example, e
Robert Bradshaw wrote:
> On Sep 27, 2007, at 4:43 AM, Jason Grout wrote:
>
>> A=A.union(B)
>>
>> to modify A?
>
> Yes. Or even
>
> A.inplace_union(B)
>
> (or some better name than that) which returns nothing. Otherwise, for
> example, every function that received a graph as an argument wou
Jason Grout wrote:
> Mike Hansen wrote:
>> Of all the code I've read in lots of different languages, I think code
>> written for Mathematica has been the least transparent.
>
> I guess I've always loved functional languages, so the simple core
> principles appealed to me right away.
See a thread
On 9/27/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> You have a good point, though fortunately we're looking for refcounts
> so low that (essentially) nothing else can be holding onto it but the
> current stack frame. If b is pointing to a, it doesn't matter how
> many other things are (direc
On Sep 27, 2007, at 7:36 AM, Fernando Perez wrote:
> On 9/27/07, Bill Page <[EMAIL PROTECTED]> wrote:
>
>> There is another very relevant thread started by Robert Bradshaw on
>> this list concerning the safety of in-place modifications:
>>
>> http://groups.google.com/group/sage-devel/browse_thre
On Sep 27, 2007, at 4:43 AM, Jason Grout wrote:
> Mike Hansen wrote:
>>> The best I've come up with at this point is, given graphs
>>> A,B,C,D,E, the
>>> union is:
>>>
>>> A.union(B).union(C).union(D).union(E)
>>>
>>> where the union function returns the modified graph each time so
>>> I can
I disagree. Maybe its because I grew up learning BASIC, but in-place
modification generally confuses and annoys me. Here's an example that
I think illustrates one of my issues:
Code version A:
a = something
b = [a,something_else]
c = a.a_method()
important_result(b)
Code version B:
a = somethin
On 9/27/07, Bill Page <[EMAIL PROTECTED]> wrote:
> There is another very relevant thread started by Robert Bradshaw on
> this list concerning the safety of in-place modifications:
>
> http://groups.google.com/group/sage-devel/browse_thread/thread/806cd958eb28ac3b/46655d7572d11ee6?#46655d7572d11e
On 9/27/07, Jason Grout wrote:
> ...
> >
> >> where the union function returns the modified graph each time so I can
> >> keep chaining union function calls. The union actually modifies the
> >> graph A, so if you want A left alone and a new graph returned, you do:
> >>
> >> newgraph=A.copy().uni
Robert Bradshaw wrote:
> On Sep 26, 2007, at 8:59 PM, Jason Grout wrote:
>
>> As for graphs, there isn't a standard definition for the "+" operation
>> that is agreed upon, even for graphs of the same type (e.g., should it
>> be disjoint union or union?). That's why I was asking about custom
>>
Chris Chiasson wrote:
> It might be worth pointing out that adding "new" syntax in Mathematica
> is (usually) done by assignments to the function that transforms
> general two dimensional input into source code. That isn't really the
> same thing as adding a new operator to the language itself.
A
Craig Citro wrote:
>>> The best I've come up with at this point is, given graphs
>>> A,B,C,D,E, the
>>> union is:
>>>
>>> A.union(B).union(C).union(D).union(E)
>> I actually think that this looks very clear, despite the lack of
>> infix operators.
>>
>
> I agree -- especially since it looks like
Mike Hansen wrote:
>> The best I've come up with at this point is, given graphs A,B,C,D,E, the
>> union is:
>>
>> A.union(B).union(C).union(D).union(E)
>>
>> where the union function returns the modified graph each time so I can
>> keep chaining union function calls. The union actually modifies t
>> The best I've come up with at this point is, given graphs
>> A,B,C,D,E, the
>> union is:
>>
>> A.union(B).union(C).union(D).union(E)
>
> I actually think that this looks very clear, despite the lack of
> infix operators.
>
I agree -- especially since it looks like a literal translation of
th
Mike Hansen wrote:
> Of all the code I've read in lots of different languages, I think code
> written for Mathematica has been the least transparent.
I guess I've always loved functional languages, so the simple core
principles appealed to me right away. Some things I love include the
consistenc
On Sep 26, 2007, at 8:59 PM, Jason Grout wrote:
> Robert Bradshaw wrote:
>> The sage coercion model guarantees that when x.__add__(y) is called
>> (well, technically x._add_ or x._add_c_impl), the argument y is of
>> the same type and parent as x. For example
>>
>> sage: R. = ZZ[]
>> sage: x+1/2
> The best I've come up with at this point is, given graphs A,B,C,D,E, the
> union is:
>
> A.union(B).union(C).union(D).union(E)
>
> where the union function returns the modified graph each time so I can
> keep chaining union function calls. The union actually modifies the
> graph A, so if you wa
Robert Bradshaw wrote:
> The sage coercion model guarantees that when x.__add__(y) is called
> (well, technically x._add_ or x._add_c_impl), the argument y is of
> the same type and parent as x. For example
>
> sage: R. = ZZ[]
> sage: x+1/2
> x + 1/2
> sage: parent(x)
> Univariate Polynomial
The sage coercion model guarantees that when x.__add__(y) is called
(well, technically x._add_ or x._add_c_impl), the argument y is of
the same type and parent as x. For example
sage: R. = ZZ[]
sage: x+1/2
x + 1/2
sage: parent(x)
Univariate Polynomial Ring in x over Integer Ring
sage: parent(
Of all the code I've read in lots of different languages, I think code
written for Mathematica has been the least transparent.
--Mike
On 9/26/07, Chris Chiasson <[EMAIL PROTECTED]> wrote:
>
> It might be worth pointing out that adding "new" syntax in Mathematica
> is (usually) done by assignment
It might be worth pointing out that adding "new" syntax in Mathematica
is (usually) done by assignments to the function that transforms
general two dimensional input into source code. That isn't really the
same thing as adding a new operator to the language itself.
On Sep 26, 2:07 pm, Jason Grout
cwitty wrote:
> On Sep 26, 7:31 am, Jason Grout <[EMAIL PROTECTED]> wrote:
>> Can we define custom infix operators? Suppose I'd like "boxproduct" to
>> be an infix operator. Could I make that work?
>>
>> Thanks,
>>
>> Jason
>
> If you're willing to put a lot of effort into the project, you migh
On Sep 26, 7:31 am, Jason Grout <[EMAIL PROTECTED]> wrote:
> Can we define custom infix operators? Suppose I'd like "boxproduct" to
> be an infix operator. Could I make that work?
>
> Thanks,
>
> Jason
If you're willing to put a lot of effort into the project, you might
be able to do something
On 26-Sep-07, at 10:13 AM, John Cremona wrote:
>
> Nostalgia for Algol68 ! The line
>
> OP OVER = (INT n,d)RAT: cancel(RAT(n,d));
>
> is taken from my implementation of rational numbers so "one half"
> could be written
>
> 1 OVER 2
>
> and I could also write
>
> DET M
The past is the present:
Nostalgia for Algol68 ! The line
OP OVER = (INT n,d)RAT: cancel(RAT(n,d));
is taken from my implementation of rational numbers so "one half"
could be written
1 OVER 2
and I could also write
DET M
for the determinant of a matrix (ok, that's prefix not infix).
Don't mock, my original tables
No, I don't think you can make custom infix operators in Python. With
something as long as 'boxproduct', you'd probably just be better off
making it a method.
--Mike
On 9/26/07, Jason Grout <[EMAIL PROTECTED]> wrote:
>
> Mike Hansen wrote:
> > Since I don't think that graphs and polytopes fall
Mike Hansen wrote:
> Since I don't think that graphs and polytopes fall under the SAGE
> coercion model, overloading operators is pretty straightforward. You
> just need to define the __add__ method in your class. x + y will call
> x.__add__(y).
>
> sage: class Foo:
> : def __add__(self
Thanks, now I understand what to do. However, I don't understand your
comment about "...the SAGE coercion model". What is an example of
that - the sage integers?
-M. Hampton
On Sep 25, 12:10 pm, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> Since I don't think that graphs and polytopes fall under
Mike Hansen wrote:
> Since I don't think that graphs and polytopes fall under the SAGE
> coercion model, overloading operators is pretty straightforward. You
> just need to define the __add__ method in your class. x + y will call
> x.__add__(y).
>
> sage: class Foo:
> : def __add__(self
Since I don't think that graphs and polytopes fall under the SAGE
coercion model, overloading operators is pretty straightforward. You
just need to define the __add__ method in your class. x + y will call
x.__add__(y).
sage: class Foo:
: def __add__(self, y):
: return 42
...
I would appreciate any tips on how to extend the + operator in this
way, since I would like to implement Minkowski sums of polytopes and
this is natural notation for that.
Marshall
On Sep 25, 10:37 am, "Mike Hansen" <[EMAIL PROTECTED]> wrote:
> In SAGE, '+' is used for union of sets. For example
In SAGE, '+' is used for union of sets. For example,
sage: a = Set([1,2])
sage: b = Set([2,3])
sage: a+b
{1, 2, 3}
Since currently, + is not defined for graphs, it'd be a natural choice.
--Mike
On 9/25/07, Jason Grout <[EMAIL PROTECTED]> wrote:
>
> I'm thinking more about how to make the Grap
41 matches
Mail list logo
