Nathan Rice wrote:
I've been running into a problem lately where I have an architecture like so:
Main class -> facade/configuration class -> low level logic class.
The main class is what the user interacts with.
The facade/config class is responsible for loading and managing the
lower level cl
On 6/11/10 10:00 AM, Nathan Rice wrote:
> I've tried using args/kwargs, however I found it difficult to avoid
> having arguments in my signature re-ordered, and it is also a source
> of bugs.
>
> Has anyone come up with a good solution for dealing with arguments in
> situations like this where you
On Sat, Jun 12, 2010 at 3:00 AM, Nathan Rice
wrote:
> I've tried using args/kwargs, however I found it difficult to avoid
> having arguments in my signature re-ordered, and it is also a source
> of bugs.
>
> Has anyone come up with a good solution for dealing with arguments in
> situations like th
I've been running into a problem lately where I have an architecture like so:
Main class -> facade/configuration class -> low level logic class.
The main class is what the user interacts with.
The facade/config class is responsible for loading and managing the
lower level classes and providing a
Well, as I'll be doing lots of multiplication, guess that GMPY is the
way to go. I'll use DecInt only for converting to strings if I find
anything interesting. This is all just kind of a theoretical aproach,
but, it can be lots of fun. Who knows if Python'll help find the
largest prime number ever?
[EMAIL PROTECTED] writes:
> Python's native longs use Karatsuba multiplication with is O(n^1.585).
> My early version of DecInt (BigDecimal) uses 4-way Toom-Cook ...
Wow, cool! Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
> [EMAIL PROTECTED] (Alex Martelli) writes:
> > As the author of gmpy, I'd like to point out that the speed difference
> > isn't all that large, if all you're doing is ordinary arithmetic -- a
> > few times at most (it can be better if you need some of GMP's
> > functionality whi
multiplication.
(in other words, Python is not N**2 for large numbers).
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] (Alex Martelli) writes:
> As the author of gmpy, I'd like to point out that the speed difference
> isn't all that large, if all you're doing is ordinary arithmetic -- a
> few times at most (it can be better if you need some of GMP's
> functionality which gmpy exposes, such as prim
<[EMAIL PROTECTED]> wrote:
...
> Python does support large numbers, but it's not very fast for such
> large numbers. There is a Python module called GMPY that uses the GMP
> (Gnu Multiple Precision) library for faster operations on large
> numbers.
As the author of gmpy
Already done for next version. Tentatively, there will be a package
called "ar" (Arbitrary Radix) and the module will be called BigInt. I'm
also working on an arbitrary radix BigFloat module.
Case
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> An early alpha-quality release is available at
> http://home.comcast.net/~casevh/
Given the module named "Decimal" in Python 2.4, I'd suggest you to rename
your library.
--
Giovanni Bajo
--
http://mail.python.org/mailman/listinfo/python-list
"Tuvas" <[EMAIL PROTECTED]> writes:
> I've been thinking about writing a program to generate the world's
> largest prime numbers, just for the fun of it. This would require being
> able to hold an 800 digit number into memory (25 megabits, or a
> little over 3 megs of memory for just one varia
For more information on how the largest prime number was found, see
www.mersenne.org.
Python does support large numbers, but it's not very fast for such
large numbers. There is a Python module called GMPY that uses the GMP
(Gnu Multiple Precision) library for faster operations on large
nu
I've been thinking about writing a program to generate the world's
largest prime numbers, just for the fun of it. This would require being
able to hold an 800 digit number into memory (25 megabits, or a
little over 3 megs of memory for just one variable...) I would also
need several smaller var
On Fri, 08 Apr 2005 10:18:05 -0700, Scott David Daniels <[EMAIL PROTECTED]>
wrote:
>Bengt Richter wrote:
>>>Aha! Same version (2.3.4):
>>>
>>>Idle:
>>>>>> 1e1
>>>1.0
>>>>>> import struct; struct.pack('d', 1e1)
>>>'\x00\x00\x00\x00\x00\x00\xf0?'
>>>(which is actually 1.0)
>
OK - I think this is it:
My last post fingering pickle was almost but not quite right*. Actually the
cuplrit is marshal, which produces the incorrect result that was noted. The bug
has nothing to do with IDLE, except that it uses marshal for inter-process
communication.
Here's the failure cas
Michael Spencer wrote:
Problem is associated with executing iteractive input in a subprocess.
>python idle.py -n
IDLE 1.1 No Subprocess
>>> 1e1
1.#INF
>>>
Really good find.
_very_ curious. Perhaps moving the float causes the problem?
Where does the value get converted to text
Michael Spencer wrote:
Problem is associated with executing iteractive input in a subprocess.
>python idle.py -n
IDLE 1.1 No Subprocess
>>> 1e1
1.#INF
>>>
Michael
It seems that the culprit is pickle - used to send messages between the IDLE
shell and the execution server.
>
Scott David Daniels wrote:
Scott David Daniels wrote:
Bengt Richter wrote:
Aha! Same version (2.3.4):
Idle:
>>> 1e1
1.0
>>> import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
>>> 1e1
Scott David Daniels wrote:
Bengt Richter wrote:
Aha! Same version (2.3.4):
Idle:
>>> 1e1
1.0
>>> import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
>>> 1e1
1.#INF
>>> import struct
Scott David Daniels wrote:
Steve Holden wrote:
Scott David Daniels wrote:
Terry Reedy wrote:
On my Windows machine with 2.2.1, I get exactly what you expected:
1e1
1.#INF
...
If you get wrong behavior on a later version, then a bug has been
introduced somewhere, even perhaps in VC 7, used for
Bengt Richter wrote:
Aha! Same version (2.3.4):
Idle:
>>> 1e1
1.0
>>> import struct; struct.pack('d', 1e1)
'\x00\x00\x00\x00\x00\x00\xf0?'
(which is actually 1.0)
python via command line (readline support):
>>> 1e1
1.#INF
>>> import struct; struct.pack('d', 1e1)
On Fri, 08 Apr 2005 09:05:39 -0700, Scott David Daniels <[EMAIL PROTECTED]>
wrote:
>Steve Holden wrote:
>> Scott David Daniels wrote:
>>
>>> Terry Reedy wrote:
>>>
On my Windows machine with 2.2.1, I get exactly what you expected:
>>> 1e1
1.#INF
...
If you g
Steve Holden wrote:
Scott David Daniels wrote:
Terry Reedy wrote:
On my Windows machine with 2.2.1, I get exactly what you expected:
1e1
1.#INF
...
If you get wrong behavior on a later version, then a bug has been
introduced somewhere, even perhaps in VC 7, used for 2.4.
Nope, it is also there
Hi All--
Windows XP, uwin running on Athlon XP 3000+:
0 [/c/users/ivanlan][1] python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 1e1
1.#INF
>>>
Metta,
Ivan
Michael Spencer wrote:
>
>
Michael Spencer <[EMAIL PROTECTED]> wrote:
>Terry Reedy wrote:
>> "Chris Fonnesbeck" <[EMAIL PROTECTED]> wrote
>>>However, on Windows (have tried on Mac, Linux) I get the following
>>>behaviour:
>>inf = 1e1
>>inf
>>>1.0
>> On my Windows machine with 2.2.1, I get exactly what you expec
Chris Fonnesbeck wrote:
> I have been developing a python module for Markov chain Monte Carlo
> estimation, in which I frequently compare variable values with a very
> large number, that I arbitrarily define as:
>
> inf = 1e1
Don't forget that you can write your own Infinity.
(Warning: Buggy
Steve Holden wrote:
Scott David Daniels wrote:
Terry Reedy wrote:
On my Windows machine with 2.2.1, I get exactly what you expected:
1e1
1.#INF
...
If you get wrong behavior on a later version, then a bug has been
introduced somewhere, even perhaps in VC 7, used for 2.4.
Nope, it is also the
Scott David Daniels wrote:
Terry Reedy wrote:
On my Windows machine with 2.2.1, I get exactly what you expected:
1e1
1.#INF
...
If you get wrong behavior on a later version, then a bug has been
introduced somewhere, even perhaps in VC 7, used for 2.4.
Nope, it is also there for 2.3.4 (May 25
Terry Reedy wrote:
"Chris Fonnesbeck" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
However, on Windows (have tried on Mac, Linux) I get the following
behaviour:
inf = 1e1
inf
1.0
while I would have expected:
1.#INF
On my Windows machine with 2.2.1, I get exactly what you ex
Terry Reedy wrote:
On my Windows machine with 2.2.1, I get exactly what you expected:
1e1
1.#INF
...
If you get wrong behavior on a later version, then a bug has been
introduced somewhere, even perhaps in VC 7, used for 2.4.
Nope, it is also there for 2.3.4 (May 25 2004, 21:17:02). This is no
"Chris Fonnesbeck" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> However, on Windows (have tried on Mac, Linux) I get the following
> behaviour:
>
inf = 1e1
inf
> 1.0
>
> while I would have expected:
>
> 1.#INF
On my Windows machine with 2.2.1, I get exactly what y
I thought it will be the same for FreeBSD, but here are the results:
FreeBSD 4.8 with Python 2.3.4
Python 2.3.4 (#2, Nov 10 2004, 05:08:39)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> inf = 1e308*2
>>> inf
Inf
>>> float('Inf
On Apr 7, 2005 3:34 PM, David M. Cooke
>
> I don't do Windows, so I can't say this will work, but try
>
> >>> inf = 1e308*2
I *do* do Windows, and that does work. The value of inf then becomes
'1.#INF' as expected. Strangely, doing
float('1.#INF')
still fails on Windows. Weird, weird.
--
Kr
Chris Fonnesbeck <[EMAIL PROTECTED]> writes:
> I have been developing a python module for Markov chain Monte Carlo
> estimation, in which I frequently compare variable values with a very
> large number, that I arbitrarily define as:
>
> inf = 1e1
>
> However, on Windows (have tried on Mac, Lin
You may want to read
http://www.python.org/peps/pep-0754.html
Part of the text reads
The IEEE 754 standard defines a set of binary representations and
algorithmic rules for floating point arithmetic. Included in the
standard is a set of constants for representing special values,
in
I have been developing a python module for Markov chain Monte Carlo
estimation, in which I frequently compare variable values with a very
large number, that I arbitrarily define as:
inf = 1e1
However, on Windows (have tried on Mac, Linux) I get the following behaviour:
>>> inf = 1e1
>>>
38 matches
Mail list logo
