In article
<[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> hi
>
> I think complex numbers should respect the "i" or "I" representation,
> instead of "j".
> No reason being cute and using a different character instead of the
> traditional representation? At least have the d
On Jun 29, 8:39 pm, Grant Edwards <[EMAIL PROTECTED]> wrote:
> On 2008-06-29, Roy Smith <[EMAIL PROTECTED]> wrote:
>
> >> I think complex numbers should respect the "i" or "I"
> >> representation, instead of "j". No reason being cute and using
> >> a different character instead of the traditional
>
On 2008-06-29, Roy Smith <[EMAIL PROTECTED]> wrote:
>> I think complex numbers should respect the "i" or "I"
>> representation, instead of "j". No reason being cute and using
>> a different character instead of the traditional
>> representation?
>
> Ask any electrical engineer what j means.
And a
In article
<[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> hi
>
> I think complex numbers should respect the "i" or "I" representation,
> instead of "j".
> No reason being cute and using a different character instead of the
> traditional representation?
Ask any electrical
On Jun 28, 1:48 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> hi
>
> I think complex numbers should respect the "i" or "I" representation,
> instead of "j".
> No reason being cute and using a different character instead of the
> traditional representation? At least have the decency of suppor
On Jun 28, 1:48 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> I think complex numbers should respect the "i" or "I" representation,
> instead of "j".
> No reason being cute and using a different character instead of the
> traditional representation? At least have the decency of supporting
>
Op 2005-01-12, It's me schreef <[EMAIL PROTECTED]>:
> Precisely. One have to convert complex number into vectors, and vector of
> complex numbers into vector of vectors, list of complex numbers into list of
> vectors, , you get the idea.
Wrong. My vector example was an illustration that you
Robert Kern wrote:
Let's presume for a moment that complex is *not* a native data type in
Python. How would we implement the above - cleanly?
The reason for making complex a builtin is _not_ to ease a single
program, but to create a convention allowing different modules
which operate on complex nu
It's me wrote:
> The world would come to a halt if all of a sudden nobody understands
complex
> numbers anymore. :-)
Actually, it would oscillate out of control.
--
CARL BANKS
--
http://mail.python.org/mailman/listinfo/python-list
"It's me" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Precisely. One have to convert complex number into vectors, and vector
> of
> complex numbers into vector of vectors, list of complex numbers into list
> of
> vectors, , you get the idea.
No, one would have a class w
It's me wrote:
"Robert Kern" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
That's *it*.
So, how would you overload an operator to do:
With native complex support:
def twice(a):
return 2*a
print twice(3+4j), twice(2), twice("abc")
Let's presume for a moment that complex is *not*
Precisely. One have to convert complex number into vectors, and vector of
complex numbers into vector of vectors, list of complex numbers into list of
vectors, , you get the idea.
And my code no longer look like the equation I have on paper...
Like I said, I've travelled down that path befo
Op 2005-01-12, It's me schreef <[EMAIL PROTECTED]>:
>
> "Robert Kern" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> That's *it*.
>
> So, how would you overload an operator to do:
>
> With native complex support:
>
> def twice(a):
> return 2*a
>
> print twice(3+4j), twice(
"Robert Kern" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> That's *it*.
So, how would you overload an operator to do:
With native complex support:
def twice(a):
return 2*a
print twice(3+4j), twice(2), twice("abc")
Let's presume for a moment that complex is *not* a nati
It's me wrote:
You are focusing on computational type applications of complex numbers. For
those, you can do it with any languages - including machine language. It's
just a matter of how much headache you want.
For instance, when constructing "software lego parts" (such as the
Matlab/Simulink typ
You are focusing on computational type applications of complex numbers. For
those, you can do it with any languages - including machine language. It's
just a matter of how much headache you want.
For instance, when constructing "software lego parts" (such as the
Matlab/Simulink type), it's very
"Big and Blue" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> It's me wrote:
> >
> > I am very happy that Python included *native* complex
number
> > support.
>
> And I have always been happy that FORTRAN supports them.
>
> > I really like Python's notion of hav
It's me wrote:
>
I am very happy that Python included *native* complex number
support.
And I have always been happy that FORTRAN supports them.
I really like Python's notion of having just one data type: the duck.
So have you considered using Python for your problem?
--
It's me <[EMAIL PROTECTED]> wrote in comp.lang.perl.misc:
[reply moved into context]
> "Anno Siegel" <[EMAIL PROTECTED]> wrote in message
> news:cs145l$8d6
>
>
>
> >
> > Like this?
> >
> > use Math::Complex;
> >
> > my $z = sqrt( -1);
> > print 1 + $z, "\n"; # prints "1+i"
> >
> >
Operator overloading (and function overloading) helps but not enough.You
have to be aware of the complex type *everywhere* you go and that's very
annoying and error prone. I've been the works with C++, and later with
Modelica. I am very happy that Python included *native* complex number
supp
It's me <[EMAIL PROTECTED]> wrote in comp.lang.perl.misc:
[reply moved to bottom into context]
> "Jürgen Exner" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > [EMAIL PROTECTED] wrote:
> > > #python supports complex numbers.
> > [...]
> >
> > So?
> >
>
> The world would come to
For those of us that works with complex numbers, having complex number as a
natively supported data type is a big advantage. Non-native add-ons are not
sufficient and lead to very awkward program code.
"Jürgen Exner" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [EMAIL PROTECTED]
J|rgen Exner wrote:
> [EMAIL PROTECTED] wrote:
>> #python supports complex numbers.
> [...]
>
> So?
>
>> # Perl doesn't support complex numbers. But there are packages that
>> supports it.
>
> The Math::Complex module is part of the standard installation
> already, no need for any "packages" (whate
[EMAIL PROTECTED] wrote:
> #python supports complex numbers.
[...]
So?
> # Perl doesn't support complex numbers. But there are packages that
> supports it.
The Math::Complex module is part of the standard installation already, no
need for any "packages" (whatever that might be).
Did you check "
24 matches
Mail list logo
