On Nov 8, 2004, at 3:08 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
No. The binary operations in Python are opcodes, as well as in
Parrot.
And both provide the snytax to override the opcode doing a method
call,
that's it.
I guess we'll just have to disagree here. I don't see
At 12:44 AM -0800 11/9/04, Jeff Clites wrote:
And again, what about Ruby? If you believe in matching the current
philosophy of the language, it won't use ops for operators (but
rather, method calls), and won't do the right thing for objects with
vtable/MMDs, and no corresponding methods.
Yes it
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:
In Python, semantically you know that you'll end up doing a method call
(or, behaving as though you had), so it's very roundabout to do a
method call by using an op which you know will fall back to doing a
On Nov 8, 2004, at 12:50 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:
In Python, semantically you know that you'll end up doing a method
call
(or, behaving as though you had), so it's very roundabout to do a
method call by
Jeff Clites [EMAIL PROTECTED] wrote:
No. The binary operations in Python are opcodes, as well as in Parrot.
And both provide the snytax to override the opcode doing a method call,
that's it.
I guess we'll just have to disagree here. I don't see any evidence of
this
UTSL please. The code is
On Nov 5, 2004, at 10:03 AM, Sam Ruby wrote:
Jeff Clites wrote:
a) As Sam says, in Python y**z is just shorthand for
y.__pow__(z)--they will compile down to exactly the same thing
(required for Python to behave correctly). Since __pow__ isn't
special, we don't need anything to support it that
On Nov 4, 2004, at 5:24 AM, Sam Ruby wrote:
[Referring to infix operators as an alternate syntax for a named method
call]
What's the downside of compiling this code in this way? If you are a
Python programmer and all the objects that you are dealing with were
created by Python code, then not
Jeff Clites writes:
On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
This is true. But how do you define a number? Do you include
floating-point? Fixed-point? Bignum? Bigrat? Complex? Surreal?
Matrix? N registers don't even begin to encompass all the numbers
out there.
Luke Palmer [EMAIL PROTECTED] wrote:
The question is, though, how do compilers think of it? That is, does
the compiler have the liberty, given the code:
$x ** $y
To emit:
pow $P0, x, y
Or must it use a named multimethod?
Well, that's a thing compilers (or their writers ;) have
On Nov 4, 2004, at 5:24 AM, Sam Ruby wrote:
From a Python or Ruby language perspective, infix operators are not
fundamental operations associated with specific types, they are
syntactic sugar for method calls.
A the moment, I'm compiling x=y**z into:
x = y.__pow__(z)
There is nothing
Jeff Clites wrote:
a) As Sam says, in Python y**z is just shorthand for
y.__pow__(z)--they will compile down to exactly the same thing
(required for Python to behave correctly). Since __pow__ isn't
special, we don't need anything to support it that we wouldn't need
for any other arbitrary
On Nov 4, 2004, at 10:30 PM, Brent 'Dax' Royal-Gordon wrote:
On Thu, 4 Nov 2004 21:46:19 -0800, Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
This is true. But how do you define a number? Do you include
floating-point? Fixed-point? Bignum?
At 1:19 AM -0800 11/4/04, Jeff Clites wrote:
On Nov 3, 2004, at 8:09 AM, Dan Sugalski wrote:
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
A single pow_p_p_p op backed by a (non-MMD) vtable entry would
make it easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Jeff Clites [EMAIL PROTECTED] wrote:
I feel like we have op-itis and vtable-itis.
I'm for sure the last one that would add an opcode or a vtable, if it's
not needed. But in that case it has to be one. The PMC can be any kind
of plain scalar and also *complex*. We have different operations with
Jeff Clites [EMAIL PROTECTED] wrote:
I.e., PMCs don't inherently exponentiate--numbers do, and you can
exponentiate PMCs by numberizing them, exponentiating, and creating a
PMC with the result.
This is true. But how do you define a number? Do you include
floating-point? Fixed-point?
On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I.e., PMCs don't inherently exponentiate--numbers do, and you can
exponentiate PMCs by numberizing them, exponentiating, and creating a
PMC with the result.
This is true. But how do you define a
On Thu, 4 Nov 2004 21:46:19 -0800, Jeff Clites [EMAIL PROTECTED] wrote:
On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
This is true. But how do you define a number? Do you include
floating-point? Fixed-point? Bignum? Bigrat? Complex? Surreal?
Matrix? N registers don't
This omission seems odd. Was this intentional?
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it
easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
- Sam Ruby
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
This omission seems odd. Was this intentional?
Nope.
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make
it easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I know I'm going to
Dan~
On Wed, 3 Nov 2004 11:09:49 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Yeah, it would. I know I'm going to regret asking, but... any reason
*not* to make it MMD? (Though I have no idea what happens if you
square a matrix)
Squaring a matrix is easy (so long as it is square).
A^2 == A *
Dan Sugalski wrote:
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
This omission seems odd. Was this intentional?
Nope.
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it
easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I
On 04/11/03 11:19 -0500, Matt Fowles wrote:
What gets more fun is raising something (usually e) to a matrix power.
Then you have to do things with the Jordan Connical form and
decompose your matrix into eigenvalues and stuff. On the plus side,
this also allows you to define the sin and cos
Jerome~
On Wed, 3 Nov 2004 18:33:28 +0100, Jerome Quelin [EMAIL PROTECTED] wrote:
Damn, is it a new rule that perl 6 summarizer should be a maths teacher? :-)
Actually, as an American I would be a lowly math teacher... ;-)
Matt
--
Computer Science is merely the post-Turing Decline of Formal
23 matches
Mail list logo
