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 sligh
Terry Reedy 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
> bugs, bu
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 specia
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 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 Sat, Mar 1, 2014 at 5:34 AM, Mark H. Harris 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 the
> concept of tra
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
>
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 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 o
On Sat, Mar 1, 2014 at 2:11 AM, Steven D'Aprano
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 <>?
>
> 'Cos we have ten fingers and in count in decimal :-P
We talk in words and characters, so we
On Fri, 28 Feb 2014 19:52:45 +1100, Chris Angelico wrote:
> On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano
> 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. Si
Uhh, the curse of not copy-pasting everything:
> >>> exp(20)
should, of course, read
>>> epx(19)
> Traceback (most recent call last):
> File "", line 1, in
> epx(19)
> File "C:\Python34\dmath_rev.py", line 27, in epx
> n *= q
> decimal.Overflow: []
>
--
https://mail.py
Mark H. Harris 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
extremely l
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 f
Mark H. Harris 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 point.
On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano 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 from that stri
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
On Fri, Feb 28, 2014 at 4:18 PM, Mark H. Harris 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 Decimal objects. They ca
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 sp
On Fri, Feb 28, 2014 at 3:41 PM, Mark H. Harris 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 interactive
mode, too.
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> Decimal('1.2345'
On Fri, Feb 28, 2014 at 1:15 PM, Mark H. Harris 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 gonna be close.
Creat
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 k
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 27 February 2014 23:00, 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 what I'm doing
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,
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.
On Fri, Feb 28, 2014 at 4:07 AM, Terry Reedy 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 feedback
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 a
On 27 February 2014 15:42, Mark H. Harris 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?
>
> um, to
On Fri, Feb 28, 2014 at 2:42 AM, Mark H. Harris 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 completely
changed
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 ha
On 27 February 2014 12:07, Mark H. Harris 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 distribution so
> that
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 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...
>
> 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 mul
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 b
On 19 February 2014 15:30, 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 module has methods for ln() and sqrt(); and that's great!
>
> I have done some rudimentary searching of the pep his
On Wed, Feb 19, 2014 at 4:10 PM, Terry Reedy 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 than sugg
On 2/19/2014 4:54 PM, Zachary Ware wrote:
On Wed, Feb 19, 2014 at 3:30 PM, Mark H. Harris 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... deci
On Wed, Feb 19, 2014 at 3:30 PM, Mark H. Harris 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 case; I'm
>
>
> 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 pyt
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 these
43 matches
Mail list logo
