On Tuesday 19 August 2008, Alan G Isaac wrote:
>
> Proposal 1: PEP 225, but *just* for multiplication.
> Either ~* as in the PEP or @* (which I prefer).
> (This looks simplest.)
>
> Proposal 2: PEP 225
> (but maybe using @ instead of ~).
>
> Proposal 3: use of a unicode character,
> perhaps × since
Hi,
Just a quick note to let you guys know that I'm the one who most
recently revived the discussion on python-dev.
My needs are research and teaching in mathematics. So ideally, the
programming notation should require only minimal explanations, and
(equally importantly), it should be easy to set
On Tue, Aug 19, 2008 at 07:57:45AM -0400, Alan G Isaac wrote:
> But we apparently agree that PEP 225 meets the need for
> a multiplication operator (with either ~ or @). Do you
> agree with Robert that *only* the multiplication operator is
> needed? (See my previous post.)
No big opinion on that.
On Tue, Aug 19, 2008 at 1:57 PM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
>> On Sun, Aug 17, 2008 at 04:28:55PM -0400, Alan G Isaac wrote:
>>> That said, what kind of problems do you have in mind?
>
> Gael Varoquaux wrote:
>> wht I am most worried about is not being able to enter the
>> symbol, bec
> On Sun, Aug 17, 2008 at 04:28:55PM -0400, Alan G Isaac wrote:
>> That said, what kind of problems do you have in mind?
Gael Varoquaux wrote:
> wht I am most worried about is not being able to enter the
> symbol, because I am in an editor I don't know, and the
> symbol is not on my keyboard.
On Tue, 2008-08-19 at 09:49 +0200, Grégory Lielens wrote:
> Using __call__ as matmul:
>b = a.I - ( (a.I)(u) / (c.I + (v/a)(u)) )(v) / a
oups, of course you do not have right-divide in this case, it would thus
read
b = a.I - (a.I) (u) ( ( c.I + (v)(a.I)(u) ).I ) (v) (a.I)
hum, given the
On Mon, 2008-08-18 at 11:21 -0600, Charles R Harris wrote:
>
>
> Tim Hochberg proposed using the call operator for matrix
> multiplication, i.e.,
>
> A(B(C))
>
> Which has the advantage of using an existing operator. It looks like
> function composition, which isn't that far off the ma
2008/8/18 Gael Varoquaux <[EMAIL PROTECTED]>:
> I actually think PEP 225 is pretty good. I have not big opinion about "~"
> vs "@".
Both of these already have meanings ("boolean not" and "decorator"),
so it's pretty much a toss-up for me. In a way, the concept of a
decorator could still apply:
@
On Sun, Aug 17, 2008 at 04:28:55PM -0400, Alan G Isaac wrote:
> That said, what kind of problems do you have in mind?
A lot of software still don't deal well with unicode (wxPython's unicode
situation under windows, for instance, in "interesting"). But wht I am
most worried about is not being able
> On Mon, Aug 18, 2008 at 12:21, Charles R Harris <[EMAIL PROTECTED]> wrote:
>> Tim Hochberg proposed using the call operator for matrix multiplication,
>> i.e.,
>> A(B(C))
Robert Kern wrote:
> It's certainly worth exploring. My personal opinion is that I could
> just use a single operator fo
On Mon, Aug 18, 2008 at 12:21, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Tim Hochberg proposed using the call operator for matrix multiplication,
> i.e.,
>
> A(B(C))
>
> Which has the advantage of using an existing operator. It looks like
> function composition, which isn't that far off the mar
On Mon, Aug 18, 2008 at 10:55 AM, Grégory Lielens <[EMAIL PROTECTED]>wrote:
> On Sat, 2008-08-16 at 22:03 -0700, Fernando Perez wrote:
> > Hi all,
> >
> > [ please keep all replies to this only on the numpy list. I'm cc'ing
> > the scipy ones to make others aware of the topic, but do NOT reply on
On Sat, 2008-08-16 at 22:03 -0700, Fernando Perez wrote:
> Hi all,
>
> [ please keep all replies to this only on the numpy list. I'm cc'ing
> the scipy ones to make others aware of the topic, but do NOT reply on
> those lists so we can have an organized thread for future reference]
>
> In the Py
On Mon, Aug 18, 2008 at 1:50 AM, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> On Aug 18, 2008, at 12:00 AM, Ondrej Certik wrote:
>> There is some inconsistency though, for example one can override A() +
>> A(), but one cannot override 1 + 1. This could (should) be fixed
>> somehow.
>
> That will never
On Aug 18, 2008, at 12:00 AM, Ondrej Certik wrote:
> There is some inconsistency though, for example one can override A() +
> A(), but one cannot override 1 + 1. This could (should) be fixed
> somehow.
That will never, ever change in Python. There's no benefit
to being able to redefine int.__add_
> On Aug 17, 2008, at 10:35 PM, Christian Heimes wrote:
>> Andrew Dalke wrote:
>>> Or write B \circledast C ? (Or \oast?) Try using Google to search
>>> for that character.
>>
> unicodedata.lookup('CIRCLED ASTERISK OPERATOR')
>> '⊛'
>>
I mean, go to Google and search for "⊛".
It finds no h
On Sun, Aug 17, 2008 at 17:00, Ondrej Certik <[EMAIL PROTECTED]> wrote:
> There is some inconsistency though, for example one can override A() +
> A(), but one cannot override 1 + 1. This could (should) be fixed
> somehow.
This is getting off-topic, but I really hope that never changes. The
differ
On Sun, Aug 17, 2008 at 7:03 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> [ please keep all replies to this only on the numpy list. I'm cc'ing
> the scipy ones to make others aware of the topic, but do NOT reply on
> those lists so we can have an organized thread for future referenc
Andrew Dalke wrote:
> Or write B \circledast C ? (Or \oast?) Try using Google to search
> for that character.
>>> unicodedata.lookup('CIRCLED ASTERISK OPERATOR')
'⊛'
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.o
Gael Varoquaux wrote:
> I am very much against unicode operators. I can see a huge
> amount of problems this will generate, for little gain.
I actually basically like PEP 225,
although I find @*, @+, etc more
readable, and to provide the right
visual emphasis. (Rather than ~*, ~+, etc.)
Additio
On Sun, Aug 17, 2008 at 1:58 PM, Andrew Dalke <[EMAIL PROTECTED]>wrote:
> On Aug 17, 2008, at 9:38 PM, Charles R Harris wrote:
>
> > And here is a bit of unicode just so we can see how it looks for
> > various folks.
> >
> > A = B⊛C
>
>
> Or write B \circledast C ? (Or \oast?) Try using Google t
On Aug 17, 2008, at 9:38 PM, Charles R Harris wrote:
> And here is a bit of unicode just so we can see how it looks for
> various folks.
>
> A = B⊛C
Or write B \circledast C ? (Or \oast?) Try using Google to search
for that character.
Andrew
On Sun, Aug 17, 2008 at 7:01 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> Aside from "more operators needed", is there a consensus
> view among the developers?
>
> Taking a user's perspective, I see a short run and a long
> run.
>
> SR: I am very comfortable with adding dot versions of operators.
On Sun, Aug 17, 2008 at 12:14 PM, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> On Sun, Aug 17, 2008 at 11:10:11AM -0700, Fernando Perez wrote:
>> > LR: It would be great to use unicode math operators.
>> > On this issue, Fortress is being foresightful.
>> > Accepting the "times" symbol would be a fa
On Sun, Aug 17, 2008 at 09:33:33PM +0200, Andrew Dalke wrote:
> Gaël Varoquaux wrote:
> > Anybody care for '.*'?
> That's border-line case, and probably on the bad
> idea side because 1.*2 already means something in
> normal Python. If added there would be a difference
> between
>1.*2
> and
>
Gaël Varoquaux wrote:
> Anybody care for '.*'?
That's border-line case, and probably on the bad
idea side because 1.*2 already means something in
normal Python. If added there would be a difference
between
1.*2
and
1 .*2
This problem already exists. Consider
>>> 1 .__str__()
'1'
>>> 1.
On Sun, Aug 17, 2008 at 11:10:11AM -0700, Fernando Perez wrote:
> > LR: It would be great to use unicode math operators.
> > On this issue, Fortress is being foresightful.
> > Accepting the "times" symbol would be a fairly small move
> > for most users, since it is in the Latin 1 extension of
> > A
Fernando Perez wrote:
> For something as big as this, they would
> definitely want to work off a real pep.
What might be interesting, for those who want to experiment
with this syntax, is to take my Python parser for Python
(python4ply - http://www.dalkescientific.com/Python/python4ply.html )
and
Nadav Horesh wrote:
> But would it be not-trivial to enter times ans alike
> unicode symbols within "normal" text editors? Otherwise it
> is a compelling proposition at first glance.
First, what is a "normal" text editor?
Handling utf-8 seems pretty common these days.
http://en.wikipedia.org/
cal Python
נושא: Re: [Numpy-discussion] Possible new multiplication operators for Python
Aside from "more operators needed", is there a consensus
view among the developers?
Taking a user's perspective, I see a short run and a long
run.
SR: I am very comfortable with adding dot versio
On Sun, Aug 17, 2008 at 6:01 AM, Alan G Isaac <[EMAIL PROTECTED]> wrote:
> Aside from "more operators needed", is there a consensus
> view among the developers?
I don't think so, but given that pep 225 exists and is fully fleshed
out, I guess it should be considered the starting point of the
discu
Aside from "more operators needed", is there a consensus
view among the developers?
Taking a user's perspective, I see a short run and a long
run.
SR: I am very comfortable with adding dot versions of operators.
I am not worried about reversing the Matlab/GAUSS meanings,
but if others are very wo
On Sat, Aug 16, 2008 at 10:22 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Geez, some of those folks in those threads are downright rude.
Python-dev is nowhere nearly as civil as these lists, which I consider
to be an asset of ours which we should always strive to protect. In
this list even
On Sat, Aug 16, 2008 at 11:03 PM, Fernando Perez <[EMAIL PROTECTED]>wrote:
> Hi all,
>
> [ please keep all replies to this only on the numpy list. I'm cc'ing
> the scipy ones to make others aware of the topic, but do NOT reply on
> those lists so we can have an organized thread for future referen
Hi all,
[ please keep all replies to this only on the numpy list. I'm cc'ing
the scipy ones to make others aware of the topic, but do NOT reply on
those lists so we can have an organized thread for future reference]
In the Python-dev mailing lists, there were recently two threads
regarding the p
35 matches
Mail list logo
