On Saturday, March 1, 2014 12:55:07 AM UTC-6, Anssi Saari wrote:
I recently watched a presentation by Jessica McKellar of PSF about what
Python needs to stay popular. Other than the obvious bits (difficulties
of limited support of Python on major platforms like Windows and mobile)
the slight
On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano st...@pearwood.info wrote:
On Fri, 28 Feb 2014 16:00:10 +1100, Chris Angelico wrote:
If we had some other tag, like 'd', we could actually construct a
Decimal straight from the source code. Since source code is a string,
it'll be constructed
Mark H. Harris harrismh777 at gmail.com writes:
On Thursday, February 27, 2014 10:26:59 PM UTC-6, Chris Angelico wrote:
Create Decimal values from strings, not from the str() of a float,
which first rounds in binary and then rounds in decimal.
Thanks Chris... another excellent
On Thursday, February 27, 2014 2:33:35 AM UTC-8, Mark H. Harris wrote:
No... was not aware of gmpy2... looks like a great project! I am wondering
why it would be sooo much faster?
For multiplication and division of ~1000 decimal digit numbers, gmpy2 is ~10x
faster. The numbers I gave were
Mark H. Harris harrismh777 at gmail.com writes:
If you get a chance, take a look at the dmath.py code on:
https://code.google.com/p/pythondecimallibrary/
Hi Mark,
here is an enhancement for your epx function.
Your current version comes with the disadvantage of potentially storing
Uhh, the curse of not copy-pasting everything:
exp(20)
should, of course, read
epx(19)
Traceback (most recent call last):
File pyshell#46, line 1, in module
epx(19)
File C:\Python34\dmath_rev.py, line 27, in epx
n *= q
decimal.Overflow: [class
On Fri, 28 Feb 2014 19:52:45 +1100, Chris Angelico wrote:
On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano st...@pearwood.info
wrote:
On Fri, 28 Feb 2014 16:00:10 +1100, Chris Angelico wrote:
If we had some other tag, like 'd', we could actually construct a
Decimal straight from the source
On Sat, Mar 1, 2014 at 2:11 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
or there needs to be a system for constructing literals
of non-built-in types. And if Decimal becomes built-in, then why that
and not insert type name here?
'Cos we have ten fingers and in count in
On Friday, February 28, 2014 8:41:49 AM UTC-6, Wolfgang Maier wrote:
Hi Mark,
here is an enhancement for your epx function.
Wolfgang
hi Wolfgang, thanks much! As a matter of point in fact, I ran into this
little snag and didn't understand it, because I was thinking that outside of
On Friday, February 28, 2014 2:54:12 AM UTC-6, Wolfgang Maier wrote:
Since by now, I guess, we all agree that using the string representation is
the wrong approach, you can simply use Decimal instead of D() throughout
your code.
Best,
Wolfgang
hi Wolfgang, ...right... I'm going to
On Friday, February 28, 2014 9:11:49 AM UTC-6, Steven D'Aprano wrote:
Now that Python has a fast C implementation of Decimal, I would be
happy for Python 4000 to default to decimal floats, and require special
syntax for binary floats. Say, 0.1b if you want a binary float, and 0.1
for a
On Sat, Mar 1, 2014 at 5:34 AM, Mark H. Harris harrismh...@gmail.com wrote:
Yes. ... and for clarification back to one of my previous comments, when I
refer to 'float' I am speaking of the IEEE binary floating point
representation built-in everywhere... including the processor!... not
On Friday, February 28, 2014 12:37:37 PM UTC-6, Chris Angelico wrote:
Are you aware that IEEE 754 includes specs for decimal floats? :)
Yes. I am from back in the day... way back... so 754 1985 is what I have
been referring to.
IEEE 854 1987 and the generalized IEEE 754 2008 have
On Friday, February 28, 2014 1:34:27 AM UTC-6, Steven D'Aprano wrote:
Now that Python has a fast C implementation of Decimal, I would be happy
for Python 4000 to default to decimal floats, and require special syntax
for binary floats. Say, 0.1b if you want a binary float, and 0.1 for a
On Friday, February 28, 2014 1:39:11 PM UTC-6, Mark H. Harris wrote:
On Friday, February 28, 2014 1:34:27 AM UTC-6, Steven D'Aprano wrote:
Now that Python has a fast C implementation of Decimal, I would be happy
for Python 4000 to default to decimal floats, and require special syntax
Terry Reedy tjre...@udel.edu writes:
On 2/27/2014 7:07 AM, Mark H. Harris wrote:
Oh, and one more thing... whoever is doing the work on IDLE these
days, nice job! It is stable, reliable, and just works/
appreciate it!
As one of 'them', thank you for the feedback. There are still some
Have you looked at the gmpy2 ( https://code.google.com/p/gmpy/ ) module?
casevh
No... was not aware of gmpy2... looks like a great project! I am wondering
why it would be sooo much faster? I was hoping that Stefan Krah's C
accelerator was using FFT fast fourier transforms for
On Wednesday, February 19, 2014 4:29:27 PM UTC-6, Oscar Benjamin wrote:
Actually the performance difference isn't as big as you might think.
Oscar
You're right. At least my own benchmark on my native exp() vs the built-in
was about ~same ~same.
I was hoping that Stefan had used FFT...
On Wednesday, February 19, 2014 4:10:22 PM UTC-6, Terry Reedy wrote:
Or just dmath. I think this is a better idea than suggesting additions
to decimal itself. For one thing, anything put in decimal would be
subject to change if the function were to be added to the standard. It
is worth
On 27 February 2014 12:07, Mark H. Harris harrismh...@gmail.com wrote:
I have created a project here:
https://code.google.com/p/pythondecimallibrary/
I wrote a dmath.py library module for use with the C accelerated decimal
module, that I would like to see merged into the C Python
On Thursday, February 27, 2014 8:42:55 AM UTC-6, Oscar Benjamin wrote:
Some points:
Thanks so much... you have clarified some things I was struggling with...
1) Why have you committed the code as a .tar.gz file?
um, to save space... well, I know its tiny, but its just a habit I
On Fri, Feb 28, 2014 at 2:42 AM, Mark H. Harris harrismh...@gmail.com wrote:
1) Why have you committed the code as a .tar.gz file?
um, to save space... well, I know its tiny, but its just a habit I
have... 5kb instead of 25kb...
When you commit changes, though, it has to treat it as a
On 27 February 2014 15:42, Mark H. Harris harrismh...@gmail.com wrote:
On Thursday, February 27, 2014 8:42:55 AM UTC-6, Oscar Benjamin wrote:
Some points:
Thanks so much... you have clarified some things I was struggling with...
1) Why have you committed the code as a .tar.gz file?
On 2/27/2014 7:07 AM, Mark H. Harris wrote:
Oh, and one more thing... whoever is doing the work on IDLE these
days, nice job! It is stable, reliable, and just works/
appreciate it!
As one of 'them', thank you for the feedback. There are still some bugs,
but I hit them seldom enough that I
On Fri, Feb 28, 2014 at 4:07 AM, Terry Reedy tjre...@udel.edu wrote:
On 2/27/2014 7:07 AM, Mark H. Harris wrote:
Oh, and one more thing... whoever is doing the work on IDLE these
days, nice job! It is stable, reliable, and just works/
appreciate it!
As one of 'them', thank you for the
On Thursday, February 27, 2014 10:24:23 AM UTC-6, Oscar Benjamin wrote:
from decimal import Decimal as D
D(0.1)
Decimal('0.155511151231257827021181583404541015625')
hi Oscar, well, that's not what I'm doing with my D()... I'm not just
making D() mimic Decimal... look
On Friday, February 28, 2014 12:00:45 AM UTC+1, Mark H. Harris wrote:
On Thursday, February 27, 2014 10:24:23 AM UTC-6, Oscar Benjamin wrote:
from decimal import Decimal as D
D(0.1)
Decimal('0.155511151231257827021181583404541015625')
hi Oscar, well, that's not
On 27 February 2014 23:00, Mark H. Harris harrismh...@gmail.com wrote:
On Thursday, February 27, 2014 10:24:23 AM UTC-6, Oscar Benjamin wrote:
from decimal import Decimal as D
D(0.1)
Decimal('0.155511151231257827021181583404541015625')
hi Oscar, well, that's not what I'm
On Thursday, February 27, 2014 5:50:55 PM UTC-6, Oscar Benjamin wrote:
. . . Calling Decimal on a float performs an exact binary to
decimal conversion. Your reasoning essentially assumes that every
float should be interpreted as an approximate representation for a
nearby decimal value.
On Thu, 27 Feb 2014 15:00:45 -0800, Mark H. Harris wrote:
Decimal does not keep 0.1 as a floating point format (regardless of
size) which is why banking can use Decimal without having to worry about
the floating formatting issue... in other words, 0.0 is not stored in
Decimal as any kind
On Fri, Feb 28, 2014 at 1:15 PM, Mark H. Harris harrismh...@gmail.com wrote:
Its just easier to type D(2.78) than Deciaml('2.78').
It's easier to type 2.78 than 2.718281828, too, but one of them is
just plain wrong. Would you tolerate using 2.78 for e because it's
easier to type? I mean, it's
On Thursday, February 27, 2014 9:15:36 PM UTC-6, Steven D'Aprano wrote:
Decimal uses base 10, so it is a better fit for numbers we
write out in base 10 like 0.12345, but otherwise it suffers from the
same sort of floating point rounding issues as floats do.
py
On Fri, Feb 28, 2014 at 3:41 PM, Mark H. Harris harrismh...@gmail.com wrote:
So, I am thinking I need to mods... maybe an idmath.py for interactive
sessions, and then dmath.py for for running within my scientific scripts...
??
No; the solution is to put quotes around your literals in
On Thursday, February 27, 2014 10:26:59 PM UTC-6, Chris Angelico wrote:
Create Decimal values from strings, not from the str() of a float,
which first rounds in binary and then rounds in decimal.
Thanks Chris... another excellent point... ok, you guys have about convinced
me (which is
On Fri, Feb 28, 2014 at 4:18 PM, Mark H. Harris harrismh...@gmail.com wrote:
do I make the assumption that all functions will take a string as argument
and then let interactive users bare the responsibility to enter a string or
decimal... avoiding floats...
Just have your users pass in
On Fri, 28 Feb 2014 16:00:10 +1100, Chris Angelico wrote:
If we had some other tag, like 'd', we could actually construct a
Decimal straight from the source code. Since source code is a string,
it'll be constructed from that string, and it'll never go via float.
Now that Python has a fast C
Would it be possible to extend the methods of the decimal module just a bit to
include atan(), sin(), cos(), and exp() ?
The module has methods for ln() and sqrt(); and that's great!
I have done some rudimentary searching of the pep history and I'm not finding
any pep related to extending the
On 2/19/2014 10:30 AM, Mark H. Harris wrote:
Would it be possible to extend the methods of the decimal module just
a bit to include atan(), sin(), cos(), and exp() ?
The decimal module implements IEEE 854
The module has methods for ln() and sqrt(); and that's great!
that includes just
The decimal module implements IEEE 854
Thanks Terry... ... long time.
I would like to find out if there is some iron-clad policy about extending the
implementation of an IEEE standard... decimal module in this case; I'm just
thinking that this particular extension really fits the
On Wed, Feb 19, 2014 at 3:30 PM, Mark H. Harris harrismh...@gmail.com wrote:
The decimal module implements IEEE 854
Thanks Terry... ... long time.
I would like to find out if there is some iron-clad policy about extending
the implementation of an IEEE standard... decimal module in this
On 2/19/2014 4:54 PM, Zachary Ware wrote:
On Wed, Feb 19, 2014 at 3:30 PM, Mark H. Harris harrismh...@gmail.com wrote:
The decimal module implements IEEE 854
Thanks Terry... ... long time.
I would like to find out if there is some iron-clad policy about extending
the implementation of an
On Wed, Feb 19, 2014 at 4:10 PM, Terry Reedy tjre...@udel.edu wrote:
On 2/19/2014 4:54 PM, Zachary Ware wrote:
You might consider suggesting a decimal.math module on python-ideas.
Or just dmath.
The name (and location) is of course endlessly bikesheddable :)
I think this is a better idea
On 19 February 2014 15:30, Mark H. Harris harrismh...@gmail.com wrote:
Would it be possible to extend the methods of the decimal module just a bit
to include atan(), sin(), cos(), and exp() ?
The module has methods for ln() and sqrt(); and that's great!
I have done some rudimentary
On Wednesday, February 19, 2014 1:30:13 PM UTC-8, Mark H. Harris wrote:
I guess what I'm really asking for are the same routines found in bc -l
math library. I've finally moved my number crunching stuff to python (from
bc) because the performance of decimal is finally way better than bc for
44 matches
Mail list logo
