On 2025-01-03, HenHanna wrote:
> On Thu, 2 Jan 2025 10:54:02 +, yeti wrote:
>
>> https://oeis.org/A000537 ?
>
> Sum of first n cubes; or n-th triangular number squared.
>
> 0, 1, 9, 36, 100, 225, 441, 784, 1296, 2025, 3025, 4356, 6084, 8281,
> 11025, 14400, 18496, 23409, 29241, 36100, 44100, 5
The April Fools joke was on those of us who never received/have yet to
receive @Stefan's OP.
On 2/04/24 08:02, Avi Gross via Python-list wrote:
Is this a April 1 post for fools.
Multiplication with an asterisk symbol is built into python.
The same symbol used in other contexts has
Is this a April 1 post for fools.
Multiplication with an asterisk symbol is built into python.
The same symbol used in other contexts has other contexts has an assortment
of largely unrelated meanings such as meaning everything when used to
import.
On Mon, Apr 1, 2024, 1:27 PM Piergiorgio
On 2024-04-01 12:35, Joel Goldstick via Python-list wrote:
On Mon, Apr 1, 2024 at 1:26 PM Piergiorgio Sartor via Python-list
^^^
from math import *
a = 2
b = 3
print( a * b )
I guess the operator "*" can be imported from any module... :-)
No import is necessary.
Of cour
t work.
> >
> > A: No, this cannot work. To multiply, you need the multiplication
> > operator. You can import the multiplication operator from "math":
> >
> > Code example:
> >
> > from math import *
> >
> >
On 01/04/2024 10.40, Stefan Ram wrote:
Q: How can I multiply two variables in Python? I tried:
a = 2
b = 3
print( ab )
but it did not work.
A: No, this cannot work. To multiply, you need the multiplication
operator. You can import the multiplication operator from
On Tue, Feb 27, 2018 at 9:02 AM, Seb wrote:
> That's right. I just tried this manipulation by replacing the last
> block of code in my example, from the line above `for` loop with:
>
> ------
> # Alternative using `np.matmul`
>
gt;>>> If A is an nx3 matrix and B is a 3x3 matrix, then C = A @ B is an
>>>> nx3 matrix where C[i] = A[i] @ B.
>>>> (This is a property of matrix multiplication in general, nothing
>>>> special about numpy.)
>>> I think that's only true if B is
g each
>>>> row (1x3) of a matrix by another matrix (3x3), compared to looping
>>>> through the matrix row by row as shown in the code.
>>
>>> Just multiply the two matrices together.
>>
>>> If A is an nx3 matrix and B is a 3x3 matrix, then C = A
ough the matrix row by row as shown in the code.
>
>> Just multiply the two matrices together.
>
>> If A is an nx3 matrix and B is a 3x3 matrix, then C = A @ B is an nx3
>> matrix where C[i] = A[i] @ B.
>
>> (This is a property of matrix multiplication in general, nothing
&
.
> Just multiply the two matrices together.
> If A is an nx3 matrix and B is a 3x3 matrix, then C = A @ B is an nx3
> matrix where C[i] = A[i] @ B.
> (This is a property of matrix multiplication in general, nothing
> special about numpy.)
I think that's only true if B is the sam
hen
C = A @ B is an nx3 matrix where C[i] = A[i] @ B.
(This is a property of matrix multiplication in
general, nothing special about numpy.)
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Feb 26, 2018 at 3:12 PM, Dan Stromberg wrote:
> On Mon, Feb 26, 2018 at 2:07 PM, Ian Kelly wrote:
>> Taking LMGTFY to a whole new level of rudeness by obviously not even
>> bothering to read the entire paragraph before responding.
>
> Is LMGTFY rude? I think maybe it was back when it sai
On Mon, Feb 26, 2018 at 2:07 PM, Ian Kelly wrote:
> On Mon, Feb 26, 2018 at 2:40 PM, Dan Stromberg wrote:
>> On Mon, Feb 26, 2018 at 8:53 AM, Seb wrote:
>>> On Sun, 25 Feb 2018 18:52:14 -0500,
>>> Terry Reedy wrote:
>>>
>>> [...]
>>>
numpy has a matrix multiply function and now the '@' mat
On Mon, Feb 26, 2018 at 2:40 PM, Dan Stromberg wrote:
> On Mon, Feb 26, 2018 at 8:53 AM, Seb wrote:
>> On Sun, 25 Feb 2018 18:52:14 -0500,
>> Terry Reedy wrote:
>>
>> [...]
>>
>>> numpy has a matrix multiply function and now the '@' matrix multiply
>>> operator.
>>
>> Yes, but what I was wonderi
On Mon, Feb 26, 2018 at 8:53 AM, Seb wrote:
> On Sun, 25 Feb 2018 18:52:14 -0500,
> Terry Reedy wrote:
>
> [...]
>
>> numpy has a matrix multiply function and now the '@' matrix multiply
>> operator.
>
> Yes, but what I was wondering is whether there's a faster way of
> multiplying each row (1x3)
On Mon, Feb 26, 2018 at 9:53 AM, Seb wrote:
> On Sun, 25 Feb 2018 18:52:14 -0500,
> Terry Reedy wrote:
>
> [...]
>
>> numpy has a matrix multiply function and now the '@' matrix multiply
>> operator.
>
> Yes, but what I was wondering is whether there's a faster way of
> multiplying each row (1x3)
On Sun, 25 Feb 2018 18:52:14 -0500,
Terry Reedy wrote:
[...]
> numpy has a matrix multiply function and now the '@' matrix multiply
> operator.
Yes, but what I was wondering is whether there's a faster way of
multiplying each row (1x3) of a matrix by another matrix (3x3), compared
to looping th
On 2/25/2018 12:45 PM, Seb wrote:
Hello,
The following is an example of an Nx3 matrix (`uvw`) representing N
vectors that need to be multiplied by a 3x3 matrix (generated by
`randint_mat` function) and store the result in `uvw_rots`:
---
Hello,
The following is an example of an Nx3 matrix (`uvw`) representing N
vectors that need to be multiplied by a 3x3 matrix (generated by
`randint_mat` function) and store the result in `uvw_rots`:
------
import numpy as np
nds=0.5*((stop-start).total_seconds()))
> datetime.datetime(2016, 2, 11, 5, 45, 45, 818009)
How about
mean = start + (stop - start) / 2
?
> Interesting thing is that total_seconds() already returns fractions of
> seconds, so it would be almost trivial to implement timedelta
> m
On Thu, Feb 11, 2016 at 9:39 PM, Nagy László Zsolt wrote:
> I have checked and it does work with Python 3. But it does not work with
> Python 2 - is there a good reason for this?
Mainly that Python 3 has had six years of development since Python
2.7, and Python 2 has been getting only bugfixes an
nteresting thing is that total_seconds() already returns fractions of
seconds, so it would be almost trivial to implement timedelta
multiplication with floats.
I have checked and it does work with Python 3. But it does not work with
Python 2 - is there a good reason for this?
Thanks,
Laszlo
--
https://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano :
> But by this time, we had already learned in secondary school that you can
> use any of the following to write multiplication:
>
> x × y
Not where I lived. (Those x's would have been a nightmare for the
teacher who had to mark people's test answers
In a message of Thu, 26 Nov 2015 05:09:13 +1100, "Steven D'Aprano" writes:
>On Thu, 26 Nov 2015 02:59 am, Laura Creighton wrote:
>
>> The great sticking point for the children I am teaching is
>> '*' means multiplication. You can really see that s
On Thu, 26 Nov 2015 02:59 am, Laura Creighton wrote:
> The great sticking point for the children I am teaching is
> '*' means multiplication. You can really see that some people
> have to make extensive mental modifications in order to handle
> the concept that mathematica
Dave Farrance wrote:
Yep, he's evidently used to the Matlab/Octave way of defining "vectors"
which is somewhat easier for a math-oriented interactive environment.
It's just a *bit* more laborious to append columns in numpy.
Yes, that's probably the main reason to do things that way.
A collecti
PythonDude wrote:
>On Thursday, 12 November 2015 22:57:21 UTC+1, Robert Kern wrote:
>> He simply instantiated the two vectors as row-vectors instead of
>> column-vectors,
>> which he could have easily done, so he had to flip the matrix expression.
>
>Thank you very much Robert - I just had to
On Thursday, 12 November 2015 22:57:21 UTC+1, Robert Kern wrote:
> On 2015-11-12 15:57, PythonDude wrote:
> > Hi all,
> >
> > I've come around a webpage with python-tutorial/description for obtaining
> > something and I'll solve this:
> >
> > R = p^T w
> >
> > where R is a vector and p^T is the t
6, 8],
> [ 0, 3, 6, 9, 12],
> [ 0, 4, 8, 12, 16]])
> py> m.T * m
> matrix([[30]])
>
> Yeah, I don't know what that person is talking about either. It looks
> correct to me.
Thank you very much, Ian - just had to be sure about this - I would also be
very disappointed in Python, if this author was right about this non-intuitive
interpretation of how to do matrix multiplication :-)
--
https://mail.python.org/mailman/listinfo/python-list
On 2015-11-12 15:57, PythonDude wrote:
Hi all,
I've come around a webpage with python-tutorial/description for obtaining
something and I'll solve this:
R = p^T w
where R is a vector and p^T is the transpose of another vector.
...
p is a Nx1 column vector, so p^T turns into a 1xN row vector w
On Thu, Nov 12, 2015 at 8:57 AM, PythonDude wrote:
> Hi all,
>
> I've come around a webpage with python-tutorial/description for obtaining
> something and I'll solve this:
>
> R = p^T w
>
> where R is a vector and p^T is the transpose of another vector.
>
> ...
> p is a Nx1 column vector, so p^T
Hi all,
I've come around a webpage with python-tutorial/description for obtaining
something and I'll solve this:
R = p^T w
where R is a vector and p^T is the transpose of another vector.
...
p is a Nx1 column vector, so p^T turns into a 1xN row vector which can be
multiplied with the
Nx1 weig
7;t see it in your compiled output could indicate a C compiler
> bug which could in turn explain the different behaviour people see from
> Python.
>
> To understand exactly why 2049 is the number where it fails consider that
> it is the smallest integer that requires 12 bits of mantis
f the x87 stack (the number
we previously stored) by the 64 bit float at 0x18 stack offset. In context
that's the number 1-.5**53 which was presumably calculated earlier. The top
of the x87 stack is overwritten with the result. This calculation is
performed using 80-bit floating point with a 64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02.07.2015 19:29, Jason Swails wrote:
> // maths.h #include #include
>
> int main() { double x; int i; x = 1-pow(0.5, 53);
>
> for (i = 1; i < 100; i++) { if ((int)(i*x) == i) {
> printf("%d\n", i); break; } }
>
> return 0; }
Does not
Laura Creighton wrote:
> In a message of Fri, 03 Jul 2015 00:52:55 +1000, "Steven D'Aprano" writes:
>>Despite the title, this is not one of the usual "Why can't Python do
>>maths?" "bug" reports.
>>
>>Can anyone reproduce this behaviour? If so, please reply with the version
>>of Python and your op
In a message of Fri, 03 Jul 2015 00:52:55 +1000, "Steven D'Aprano" writes:
>Despite the title, this is not one of the usual "Why can't Python do
>maths?" "bug" reports.
>
>Can anyone reproduce this behaviour? If so, please reply with the version of
>Python and your operating system. Printing sys.ve
On Fri, Jul 3, 2015 at 11:13 AM, Oscar Benjamin
wrote:
> On 2 July 2015 at 18:29, Jason Swails wrote:
> >
> > As others have suggested, this is almost certainly a 32-bit vs. 64-bit
> > issue. Consider the following C program:
> >
> > // maths.h
> > #include
> > #include
> >
> > int main() {
>
On 3-7-2015 7:07, Ned Deily wrote:
> In article <559579bb$0$2921$e4fe5...@news.xs4all.nl>,
> Irmen de Jong wrote:
>> Tested on Mac OSX 10.10.4, with a 64-bit core2duo processor. Below are all
>> 64-bit python
>> implementations:
>> 2.6.9 (apple supplied), 2.7.6 (apple supplied), 3.4.3 (homebrew)
On 2 July 2015 at 18:29, Jason Swails wrote:
>
> As others have suggested, this is almost certainly a 32-bit vs. 64-bit
> issue. Consider the following C program:
>
> // maths.h
> #include
> #include
>
> int main() {
> double x;
> int i;
> x = 1-pow(0.5, 53);
>
> for (i = 1; i <
In article <559579bb$0$2921$e4fe5...@news.xs4all.nl>,
Irmen de Jong wrote:
> Tested on Mac OSX 10.10.4, with a 64-bit core2duo processor. Below are all
> 64-bit python
> implementations:
> 2.6.9 (apple supplied), 2.7.6 (apple supplied), 3.4.3 (homebrew), and
> pypy-2.6.0
> (homebrew). I don't h
Steven D'Aprano wrote:
> Despite the title, this is not one of the usual "Why can't Python do
> maths?" "bug" reports.
>
> Can anyone reproduce this behaviour? If so, please reply with the version
> of Python and your operating system. Printing sys.version will probably
> do.
On Kubuntu 15.04,
On 2-7-2015 16:52, Steven D'Aprano wrote:
> Despite the title, this is not one of the usual "Why can't Python do
> maths?" "bug" reports.
>
> Can anyone reproduce this behaviour? If so, please reply with the version of
> Python and your operating system. Printing sys.version will probably do.
>
>
On Thu, Jul 2, 2015 at 10:52 AM, Steven D'Aprano
wrote:
> Despite the title, this is not one of the usual "Why can't Python do
> maths?" "bug" reports.
>
> Can anyone reproduce this behaviour? If so, please reply with the version
> of
> Python and your operating system. Printing sys.version will
On 2015-07-03 00:52, Steven D'Aprano wrote:
> x = 1 - 1/2**53
> assert x == 0.
> for i in range(1, 100):
> if int(i*x) == i:
> print(i); break
tkc@debian:~$ python
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credit
On 2015-07-02 15:52, Steven D'Aprano wrote:
Despite the title, this is not one of the usual "Why can't Python do
maths?" "bug" reports.
Can anyone reproduce this behaviour? If so, please reply with the version of
Python and your operating system. Printing sys.version will probably do.
x = 1 -
On 02/07/15 15:52, Steven D'Aprano wrote:
> Despite the title, this is not one of the usual "Why can't Python do
> maths?" "bug" reports.
>
> Can anyone reproduce this behaviour? If so, please reply with the version of
> Python and your operating system. Printing sys.version will probably do.
>
>
On Thu, Jul 2, 2015 at 5:29 PM, Robin Becker wrote:
>
>
> $ uname -a
> Linux everest 4.0.6-1-ARCH #1 SMP PREEMPT Tue Jun 23 14:40:31 CEST 2015
> i686 GNU/Linux
>
I am wondering if this is a 32bit vs. 64bit thing. Has anyone gotten this
problem to work on a 64bit python?
--
https://mail.python
On Fri, 3 Jul 2015 12:52 am, Steven D'Aprano wrote:
> x = 1 - 1/2**53
Ooops, sorry I forgot that I had already run "from __future__ import
division". Otherwise that line needs to be:
x = 1 - 1.0/2**53
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, 3 Jul 2015 01:34 am, Chris Angelico wrote:
> From previous discussions I happen to know that Steven normally runs
> everything with "from __future__ import division" active (and possibly
> others? not sure), so just assume he means to work with floats here.
> Steven, I think this is one of
On Thu, Jul 2, 2015 at 9:26 AM, Paul Rubin wrote:
> Steven D'Aprano writes:
>> x = 1 - 1/2**53
>> assert x == 0.
>
> In Python 2.x I don't see how that assert can possibly succeed, since
> x is the integer 1. But I tested it anyway on 2.7.5 under Fedora 19
> and it threw an asser
On Fri, Jul 3, 2015 at 1:26 AM, Paul Rubin wrote:
> Steven D'Aprano writes:
>> x = 1 - 1/2**53
>> assert x == 0.
>
> In Python 2.x I don't see how that assert can possibly succeed, since
> x is the integer 1. But I tested it anyway on 2.7.5 under Fedora 19
> and it threw an asser
On Thu, Jul 2, 2015 at 9:28 AM, Ian Kelly wrote:
> On my Chromebook, using Python 2.7.6 from the Ubuntu Trusty
> distribution, I get AssertionError, and x == 1.
>
> In Python 3.4.0 on the same system, the code runs to completion. Both
> Pythons appear to be 64-bit builds.
>
> On my Mint 17.1 deskt
Steven D'Aprano writes:
> x = 1 - 1/2**53
> assert x == 0.
In Python 2.x I don't see how that assert can possibly succeed, since
x is the integer 1. But I tested it anyway on 2.7.5 under Fedora 19
and it threw an assertion error.
I changed it to say 1 - 1/2.0**53 and then the lo
$ uname -a
Linux everest 4.0.6-1-ARCH #1 SMP PREEMPT Tue Jun 23 14:40:31 CEST 2015 i686
GNU/Linux
robin@everest:~
$ python2
Python 2.7.10 (default, May 26 2015, 04:28:58)
[GCC 5.1.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1.0 - 1.0/2**53
>>> as
On my Chromebook, using Python 2.7.6 from the Ubuntu Trusty
distribution, I get AssertionError, and x == 1.
In Python 3.4.0 on the same system, the code runs to completion. Both
Pythons appear to be 64-bit builds.
On my Mint 17.1 desktop (which should be using the same packages), I
get the same r
Le 02/07/2015 16:52, Steven D'Aprano a écrit :
Despite the title, this is not one of the usual "Why can't Python do
maths?" "bug" reports.
Can anyone reproduce this behaviour? If so, please reply with the version of
Python and your operating system. Printing sys.version will probably do.
x = 1
On 02/07/2015 15:52, Steven D'Aprano wrote:
Despite the title, this is not one of the usual "Why can't Python do
maths?" "bug" reports.
Can anyone reproduce this behaviour? If so, please reply with the version of
Python and your operating system. Printing sys.version will probably do.
x = 1 -
On Fri, Jul 3, 2015 at 12:52 AM, Steven D'Aprano wrote:
> Can anyone reproduce this behaviour? If so, please reply with the version of
> Python and your operating system. Printing sys.version will probably do.
>
>
> x = 1 - 1/2**53
> assert x == 0.
> for i in range(1, 100):
>
hi Steven,
I'm running python-3.4.2 on a linuxmint16 box and CANNOT reproduce
it is just that
int(i*x) == i
is never True!
hope that helps
regards
Michael
* Steven D'Aprano [2015-07-02 16:56]:
> Despite the title, this is not one of the usual "Why can't Python do
> maths?" "bug" reports.
>
> C
The loop runs to completion for me on openSUSE Tumbleweed and both Python
2.7 64bits and Python 3.4 64bits.
On Thu, Jul 2, 2015 at 4:52 PM, Steven D'Aprano wrote:
> Despite the title, this is not one of the usual "Why can't Python do
> maths?" "bug" reports.
>
> Can anyone reproduce this behavio
Despite the title, this is not one of the usual "Why can't Python do
maths?" "bug" reports.
Can anyone reproduce this behaviour? If so, please reply with the version of
Python and your operating system. Printing sys.version will probably do.
x = 1 - 1/2**53
assert x == 0.
for i i
3.59404027961e+305
This must be doing integer division and then converting the result to
float, which it can.
Why the behavior is different in the case of the multiplication?
>>> 2 ** 1025 * 2**-10
Mathematically this is the same thing, but computationally, it is
to float
When the result is inside the limits, we get the right value:
>>> 2 ** 1025 / 2**10
3.59404027961e+305
Why the behavior is different in the case of the multiplication?
>>> 2 ** 1025 * 2**-10
Traceback (most recent call last):
File "&quo
On Wed, Sep 28, 2011 at 4:28 PM, Tim Roberts wrote:
> My guess is that you actually typed
> p=3*a
> instead of
> p=2*a
>
> That produces 45.
>
Or alternatively, that you used an interactive Python environment and
didn't clear i between runs.
ChrisA
--
http://mail.python.org/mailman/listin
sakthi wrote:
>In the following code,
>>>> l=[1,2,3,4,5]
>>>> i=0
>>>> for a in l:
>... p=2*a
>... t=p+i
>... i=t
>...
>>>> t
>45
>
>Python gives an answer as 45. But i am getting 30 when i execute
>manually.
;>> ... p=2*a
>>> ... t=p+i
>>> ... i=t
>>> ...
>>>>>> t
>>> 45
>>
>>> Python gives an answer as 45. But i am getting 30 when i execute
>>> manually. Is there any different multiplication pattern in python?
>&
of python are you using (and what
OS) so that we can run the code in the same environment as you.
Becky Lewis
>
> > > Python gives an answer as 45. But i am getting 30 when i execute
> > > manually. Is there any different multiplication pattern in python?
> > > Thank
> >>> for a in l:
> ... p=2*a
> ... t=p+i
> ... i=t
> ...
> >>> t
> 45
>
> Python gives an answer as 45. But i am getting 30 when i execute
> manually. Is there any different multiplication pattern in python?
> Thank yu.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
> ...
> >>>> t
> > 45
>
> > Python gives an answer as 45. But i am getting 30 when i execute
> > manually. Is there any different multiplication pattern in python?
> > Thank yu.
>
> My Python gives 30; methinks perhaps you've elided so
On 09/27/2011 10:21 AM, sakthi wrote:
In the following code,
l=[1,2,3,4,5]
i=0
for a in l:
... p=2*a
... t=p+i
... i=t
...
t
45
Python gives an answer as 45. But i am getting 30 when i execute
manually. Is there any different multiplication pattern in python?
Thank yu.
I think
, sakthi wrote:
> In the following code,>>> l=[1,2,3,4,5]
> >>> i=0
> >>> for a in l:
>
> ... p=2*a
> ... t=p+i
> ... i=t
> ...>>> t
>
> 45
>
> Python gives an answer as 45. But i am getting 30 when i execute
> ma
On Sep 27, 1:21 pm, sakthi wrote:
> In the following code,>>> l=[1,2,3,4,5]
> >>> i=0
> >>> for a in l:
>
> ... p=2*a
> ... t=p+i
> ... i=t
> ...>>> t
>
> 45
>
> Python gives an answer as 45. But i am getting 30
5. But i am getting 30 when i execute
> manually. Is there any different multiplication pattern in python?
> Thank yu.
My Python gives 30; methinks perhaps you've elided some important part
of your code.
Also, I note that your loop body can be significantly simplified to
just: i += 2*a
Cheers,
Chris
--
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
In the following code,
>>> l=[1,2,3,4,5]
>>> i=0
>>> for a in l:
... p=2*a
... t=p+i
... i=t
...
>>> t
45
Python gives an answer as 45. But i am getting 30 when i execute
manually. Is there any different multiplication pattern in python?
Thank yu
And then we learned in class what happens when you're calculating "0.1" with
different precision in the industry.
http://www.ima.umn.edu/~arnold/disasters/patriot.html
Beware.
On Tue, Sep 6, 2011 at 3:14 AM, Thomas Rachel <
nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de> wrot
On 9/7/2011 12:51 AM, Steven D'Aprano wrote:
So given a float x, when you square it you get this:
Exact values: a*a = a**2
Float values: x*x = (a+e)(a+e)
= a**2 + 2*a*e + e**2
So the error term has increased from e to (2*a*e+e**2). It is usual to
assume that e**2 is small e
doubles.)
The reason why the error is different from the 2*a*e is, that we
encounter two problems.
first problem is, that x = a + e
e exists because a float does have a limited number (let's call it N) of
digits and a has an infinite amount of non zero digits in the binary format.
se
Any
time you multiply two numbers, both numbers can always be re-written as a
sum of two numbers:
10*5 = (6+4)*(2+3)
So a perfect square can always be re-written in the form where the binomial
theorem applies:
5*5 = (2+3)*(2+3)
25 = 2*2 + 2*3 + 3*2 + 3*3
25 = 4 + 6 + 6 + 9
25 = 25
The binomial
es, since binary logic
does not support multiplication]
IOW, the error does propagate into the result indeed, but not as you
described. Indeed, thanks to rounding on assignment and multiplication
(i. e., setting register values or IEEE-754 floating-point mantissa and
exponent), the error will be
Am 06.09.2011 07:57 schrieb xyz:
hi all:
As we know , 1.1 * 1.1 is 1.21 .
But in python ,I got following :
1.1 * 1.1
1.2102
why python get wrong result? Who can tell me where's the 0.0002
from?
1.1 does not fit in a binary floating point number. It is approximate
Gary Herron wrote:
> (But try:
>print 1.1*1.1
> and see that the print statement does hide the roundoff error from you.)
That varies according to the version of Python you are using. On my system:
Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)]
on win32
Type "help
On Tue, 6 Sep 2011 03:57 pm xyz wrote:
> hi all:
>
> As we know , 1.1 * 1.1 is 1.21 .
> But in python ,I got following :
>
1.1 * 1.1
> 1.2102
The problem is that 1.1 is a *decimal* number, but computers use *binary*,
and it is impossible to express 1.1 exactly as a binary num
On 09/05/2011 10:57 PM, xyz wrote:
hi all:
As we know , 1.1 * 1.1 is 1.21 .
But in python ,I got following :
1.1 * 1.1
1.2102
why python get wrong result? Who can tell me where's the 0.0002
from?
It's not a python errorIt's the nature of floating point arithm
On Mon, Sep 5, 2011 at 10:57 PM, xyz wrote:
> hi all:
>
> As we know , 1.1 * 1.1 is 1.21 .
> But in python ,I got following :
>
1.1 * 1.1
> 1.2102
>
> why python get wrong result?
It's not Python's fault per se, rather it's the inherent nature of
binary floating-point arithmetic
hi all:
As we know , 1.1 * 1.1 is 1.21 .
But in python ,I got following :
>>> 1.1 * 1.1
1.2102
why python get wrong result? Who can tell me where's the 0.0002
from?
--
http://mail.python.org/mailman/listinfo/python-list
I'm far from sure that such a patch would be accepted. :-) Indeed,
Tim Peters has been heard to mention that if he were to do it all
again, he probably wouldn't even have implemented Karatsuba [1].
Asymptotically fast integer multiplication is a specialist need that's
already av
On Jul 7, 1:30 am, Ulrich Eckhardt
wrote:
> Billy Mays wrote:
> > On 07/06/2011 04:02 PM, Ian Kelly wrote:
> >> According to Wikipedia:
>
> >> """
> >> In practice the Schönhage–Strassen algorithm starts to outperform
> >> o
Hi,
Billy Mays wrote:
>
>> On 07/06/2011 04:02 PM, Ian Kelly wrote:
>> > On Wed, Jul 6, 2011 at 1:30 PM, Billy Mays wrote:
>> >> I was looking through the python source and noticed that long
>> multiplication
>> >> is done using the Karatsuba m
On Thu, Jul 7, 2011 at 9:49 AM, Ian Kelly wrote:
> On Thu, Jul 7, 2011 at 2:30 AM, Ulrich Eckhardt
> wrote:
>> Even worse, most people would actually pay for its use, because they don't
>> use numbers large enough to merit the Schönhage–Strassen algorithm.
>
> As it stands, Karatsuba is only used
On Thu, Jul 7, 2011 at 2:30 AM, Ulrich Eckhardt
wrote:
> Even worse, most people would actually pay for its use, because they don't
> use numbers large enough to merit the Schönhage–Strassen algorithm.
As it stands, Karatsuba is only used for numbers greater than a
specific threshold. Adding Sch
Billy Mays wrote:
> On 07/06/2011 04:02 PM, Ian Kelly wrote:
>> According to Wikipedia:
>>
>> """
>> In practice the Schönhage–Strassen algorithm starts to outperform
>> older methods such as Karatsuba and Toom–Cook multiplication for
>>
On Wed, 06 Jul 2011 22:05:52 +0200, Christian Heimes wrote:
> On the other hand FFT are based on e, complex numbers or
> trigonometric functions (=floats), which mean you'll get rounding errors.
It's possible to perform a DFT over any field. Schoenhage-Strassen uses
a DFT over a finite field (int
I also know they have guards to prevent rounding errors so I
> don't think it would be impossible to implement.
It might work for medium large longs but how about really large longs
like 5 * 1,000**10,000? I'm not familiar with FFT based multiplication
but I guess that very large numb
On Wed, Jul 6, 2011 at 2:21 PM, Billy Mays wrote:
> Side note: Are Numpy/Scipy the libraries you are referring to?
I was thinking more of gmpy or mpmath, but I'm not personally well
acquainted with any of them.
--
http://mail.python.org/mailman/listinfo/python-list
On 07/06/2011 04:02 PM, Ian Kelly wrote:
On Wed, Jul 6, 2011 at 1:30 PM, Billy Mays wrote:
I was looking through the python source and noticed that long multiplication
is done using the Karatsuba method (O(~n^1.5)) rather than using FFTs O(~n
log n). I was wondering if there was a reason the
On 07/06/2011 04:05 PM, Christian Heimes wrote:
Am 06.07.2011 21:30, schrieb Billy Mays:
I was looking through the python source and noticed that long
multiplication is done using the Karatsuba method (O(~n^1.5)) rather
than using FFTs O(~n log n). I was wondering if there was a reason the
Am 06.07.2011 21:30, schrieb Billy Mays:
> I was looking through the python source and noticed that long
> multiplication is done using the Karatsuba method (O(~n^1.5)) rather
> than using FFTs O(~n log n). I was wondering if there was a reason the
> Karatsuba method was chosen
On Wed, Jul 6, 2011 at 1:30 PM, Billy Mays wrote:
> I was looking through the python source and noticed that long multiplication
> is done using the Karatsuba method (O(~n^1.5)) rather than using FFTs O(~n
> log n). I was wondering if there was a reason the Karatsuba method was
> cho
1 - 100 of 212 matches
Mail list logo
