Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #66694 > unrolled thread

extend methods of decimal module

Back to article view | Back to comp.lang.python

Contents

  extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-19 07:30 -0800
    Re: extend methods of decimal module Terry Reedy <tjreedy@udel.edu> - 2014-02-19 13:59 -0500
      Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-19 13:30 -0800
        Re: extend methods of decimal module Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-19 15:54 -0600
        Re: extend methods of decimal module Terry Reedy <tjreedy@udel.edu> - 2014-02-19 17:10 -0500
          Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-27 04:07 -0800
            Re: extend methods of decimal module Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-02-27 14:42 +0000
              Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-27 07:42 -0800
                Re: extend methods of decimal module Chris Angelico <rosuav@gmail.com> - 2014-02-28 02:57 +1100
                Re: extend methods of decimal module Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-02-27 16:24 +0000
                  Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-27 15:00 -0800
                    Re: extend methods of decimal module Wolfgang <xpysol@gmail.com> - 2014-02-27 15:43 -0800
                    Re: extend methods of decimal module Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-02-27 23:50 +0000
                      Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-27 18:15 -0800
                        Re: extend methods of decimal module Chris Angelico <rosuav@gmail.com> - 2014-02-28 15:26 +1100
                          Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-27 21:18 -0800
                            Re: extend methods of decimal module Chris Angelico <rosuav@gmail.com> - 2014-02-28 16:26 +1100
                            Re: extend methods of decimal module Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> - 2014-02-28 08:54 +0000
                              Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 10:23 -0800
                    Re: extend methods of decimal module Steven D'Aprano <steve@pearwood.info> - 2014-02-28 03:15 +0000
                      Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-27 20:41 -0800
                        Re: extend methods of decimal module Chris Angelico <rosuav@gmail.com> - 2014-02-28 16:00 +1100
                          Re: extend methods of decimal module Steven D'Aprano <steve@pearwood.info> - 2014-02-28 07:34 +0000
                            Re: extend methods of decimal module Chris Angelico <rosuav@gmail.com> - 2014-02-28 19:52 +1100
                              Re: extend methods of decimal module Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-28 15:11 +0000
                                Re: extend methods of decimal module Chris Angelico <rosuav@gmail.com> - 2014-03-01 02:36 +1100
                                Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 10:34 -0800
                                  Re: extend methods of decimal module Chris Angelico <rosuav@gmail.com> - 2014-03-01 05:37 +1100
                                    Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 11:26 -0800
                            Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 11:39 -0800
                              Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 12:17 -0800
            Re: extend methods of decimal module Terry Reedy <tjreedy@udel.edu> - 2014-02-27 12:07 -0500
              Re: extend methods of decimal module Anssi Saari <as@sci.fi> - 2014-03-01 08:55 +0200
                Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 16:49 -0800
            Re: extend methods of decimal module Chris Angelico <rosuav@gmail.com> - 2014-02-28 04:48 +1100
        Re: extend methods of decimal module Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-19 16:27 -0600
        Re: extend methods of decimal module casevh@gmail.com - 2014-02-19 21:11 -0800
          Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-27 02:33 -0800
            Re: extend methods of decimal module casevh@gmail.com - 2014-02-28 06:23 -0800
    Re: extend methods of decimal module Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-02-19 22:29 +0000
      Re: extend methods of decimal module "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-27 02:37 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#67193

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').as_tuple()
> DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-4)
> 
> py> Decimal('1234.5').as_tuple()
> DecimalTuple(sign=0, digits=(1, 2, 3, 4, 5), exponent=-1)
> 

Steven, thank you, your explanation here is splendid, and has cleared up some of my confusion about Decimal, and given me a tool besides ('preciate it !)   I did not investigate .as_tuple()   nice.

Take a look at this:  From IDLE

>>> from decimal import *
>>> s=Decimal(.1)
>>> s.as_tuple()
DecimalTuple(sign=0, digits=(1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 5, 5, 1, 1, 1, 5, 1, 2, 3, 1, 2, 5, 7, 8, 2, 7, 0, 2, 1, 1, 8, 1, 5, 8, 3, 4, 0, 4, 5, 4, 1, 0, 1, 5, 6, 2, 5), exponent=-55)
>>>
>>> s=Decimal('.1')    <===== .1 as string
>>> s.as_tuple()
DecimalTuple(sign=0, digits=(1,), exponent=-1)
>>> 

Big difference, yes?    You have hit the nail on the head, because as you say, it is very unfortunate that the function does not know whether it has been typed in by hand (a big problem) or whether it comes from an intermediate calculated result (maybe an even bigger problem.   rats().

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...  ??

Thanks for your input.

kind regards,

[toc] | [prev] | [next] | [standalone]

#67195

On Fri, Feb 28, 2014 at 3:41 PM, Mark H. Harris <harrismh777@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 interactive
mode, too. There's no difference between interactive and script mode,
and adding magic to interactive mode will only cause confusion.

Alternatively, there is another solution that's been posited from time
to time: Decimal literals. We currently have three forms of numeric
literal, which create three different types of object:

>>> type(1)
<class 'int'>
>>> type(.1)
<class 'float'>
>>> type(1j)
<class 'complex'>

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.
Something like this:

>>> type(0.1d)
<class 'decimal.Decimal'>

which currently is a SyntaxError, so it wouldn't collide with
anything. The question is how far Python wants to bless the Decimal
type with syntax - after all, if Decimal can get a literal notation,
why can't Fraction, and why can't all sorts of other types? And that's
a huge can of worms.

ChrisA

[toc] | [prev] | [next] | [standalone]

#67203

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 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 
decimal.

But for now, backwards-compatibility requires that the default floating 
point type remains binary float. But we could maybe agitate for a 1.234d 
Decimal literal type. Care to write a PEP?

:-)


> The question is how far Python wants to bless the Decimal type with
> syntax - after all, if Decimal can get a literal notation, why can't
> Fraction, and why can't all sorts of other types? And that's a huge can
> of worms.

I like Fractions, but I don't think they're important enough for the 
average users to require literal notation.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#67208

On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano <steve@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 from that string, and it'll never go via float.
>
> 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
> decimal.

Maybe, but I believe the cdecimal module is still slower than typical
floating point. There'd also be considerations regarding NumPy and how
you'd go about working with an array of non-integer values, and so on.
Certainly this will be an extremely reasonable topic of discussion
once there's any notion of a Py4K on the cards. There'll be arguments
on both sides.

> But for now, backwards-compatibility requires that the default floating
> point type remains binary float. But we could maybe agitate for a 1.234d
> Decimal literal type. Care to write a PEP?
>
> :-)

Heh. Strong consideration here: it would mean importing the decimal
module on startup.

>>> t=time.time(); import decimal; time.time()-t
4.5000159740448
>>> t=time.time(); import decimal; time.time()-t
0.0

A dummy import (when it's already loaded) is so fast that it's
immeasurable, but four and a half seconds to load up decimal? This is
3.4.0b2 on Windows, btw. It was a lot quicker on my Linux box,
probably because the OS or disk cache had the file. So maybe it
wouldn't be too bad in practice; but it's still a cost to consider.

>> The question is how far Python wants to bless the Decimal type with
>> syntax - after all, if Decimal can get a literal notation, why can't
>> Fraction, and why can't all sorts of other types? And that's a huge can
>> of worms.
>
> I like Fractions, but I don't think they're important enough for the
> average users to require literal notation.

Yeah, but where do you draw the line? Either decimal.Decimal becomes a
built-in type, 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>>?

Also, if Decimal becomes a built-in type, does that affect the numeric tower?

ChrisA

[toc] | [prev] | [next] | [standalone]

#67230

On Fri, 28 Feb 2014 19:52:45 +1100, Chris Angelico wrote:

> On Fri, Feb 28, 2014 at 6:34 PM, Steven D'Aprano <steve@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 from that string, and it'll never go via float.
>>
>> 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 decimal.
> 
> Maybe, but I believe the cdecimal module is still slower than typical
> floating point. 

Yes, cdecimal is about 10 times slower than binary floats.

But the point is, for most applications, that will be plenty fast enough. 
And for those where it isn't, there's always binary.


> There'd also be considerations regarding NumPy and how
> you'd go about working with an array of non-integer values, and so on.

I would expect that numpy 4000 would still use binary floats internally, 
and simply so a one-off conversion of decimals to floats when you 
initalise the array. Converting decimals to floats is no less accurate 
than converting base-ten strings to floats, so there's no loss there.

[...]
>> But for now, backwards-compatibility requires that the default floating
>> point type remains binary float. But we could maybe agitate for a
>> 1.234d Decimal literal type. Care to write a PEP?
>>
>> :-)
> 
> Heh. Strong consideration here: it would mean importing the decimal
> module on startup.
> 
>>>> t=time.time(); import decimal; time.time()-t
> 4.5000159740448
>>>> t=time.time(); import decimal; time.time()-t
> 0.0
> 
> A dummy import (when it's already loaded) is so fast that it's
> immeasurable, but four and a half seconds to load up decimal? This is
> 3.4.0b2 on Windows, btw. It was a lot quicker on my Linux box, probably
> because the OS or disk cache had the file. So maybe it wouldn't be too
> bad in practice; but it's still a cost to consider.

I would expect that by the time Python 4000 has a concrete 
implementation, that figure will be a lot lower. Either due to software 
optimisations, or just the general increase in speed in computer hardware.



>>> The question is how far Python wants to bless the Decimal type with
>>> syntax - after all, if Decimal can get a literal notation, why can't
>>> Fraction, and why can't all sorts of other types? And that's a huge
>>> can of worms.
>>
>> I like Fractions, but I don't think they're important enough for the
>> average users to require literal notation.
> 
> Yeah, but where do you draw the line? Either decimal.Decimal becomes a
> built-in type, 

That's where you draw the line. Binary floats for speed, decimals for 
compatibility with school arithmetic. (Well, mostly compatible.)


> 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 decimal :-P


> Also, if Decimal becomes a built-in type, does that affect the numeric
> tower?

I don't see why whether the type is built-in or not should affect its 
position in the numeric tower. (I would expect that by the time Python 
4000 comes around, Decimal will be nicely integrated in the tower.)


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#67233

On Sat, Mar 1, 2014 at 2:11 AM, Steven D'Aprano
<steve+comp.lang.python@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 decimal :-P

We talk in words and characters, so we have an inbuilt Unicode type.
We count in decimal using Arabic numerals, so we have an inbuilt
Decimal type. We also learn, in grade school, to manipulate vulgar
fractions, so should Fraction be inbuilt? And we use transcendental
numbers, too. And ordered mappings - most real-world interpretations
of "dictionary" include that it's sorted alphabetically. Not all of
them need to be inbuilt.

>> Also, if Decimal becomes a built-in type, does that affect the numeric
>> tower?
>
> I don't see why whether the type is built-in or not should affect its
> position in the numeric tower. (I would expect that by the time Python
> 4000 comes around, Decimal will be nicely integrated in the tower.)

Well, it's more important if it's the default (and asking for an
explicit float if you want it), but it would still be a bit odd for
just one of the built-in numeric types to not have a place in an
otherwise-tidy tower. But definitely, if it's the default, we have to
ask: what about complex numbers? Are they now two Decimals? Can we get
complex floats? And does all this mean there's a massive duplication
going on? What happens if you sum() a Decimal, a float, a Decimal
complex, and a float complex? What's the resulting type? All these
questions would have to be answered.

That said, though, I would support the addition of a Decimal literal,
and start encouraging its use. Python startup performance is a cost,
but maybe the cost of Decimal could be either reduced or deferred till
first use, so that's not so obvious. Being able to tell people "Just
type 0.1d and it'll be more accurate at the expense of being slower"
would be a significant gain.

But someone else can champion that PEP :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#67240

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 decimal. 

> Steven

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 tracking a floating point, say in decimal for instance.

Isn't it amazing...  the IEEE binary float or double  is so entrenched (including the processor) that even though it has inherent problems... we are kinda stuck with it for a while. 

I have been thinking that we need extended instructions in the processor (similar to MMX) to handle accelerating decimal float floating point arithmetic, as in the decimal module. Back in the day when memory was expensive binary floats made sense... but today there is no reason to continue to stick with that limitation.

And on the other hand,  think of all the amazing things folks have done with floats and doubles... all these years.

marcus

[toc] | [prev] | [next] | [standalone]

#67241

On Sat, Mar 1, 2014 at 5:34 AM, Mark H. Harris <harrismh777@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 the concept of tracking a floating point, say in decimal for instance.
>

Are you aware that IEEE 754 includes specs for decimal floats? :)

http://en.wikipedia.org/wiki/IEEE_floating_point#Basic_formats

ChrisA

[toc] | [prev] | [next] | [standalone]

#67245

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 the specs for decimal floating point included. Everyone is thinking in the same general direction...   its kinda like the Y2K problem based on a stupid limit that because of entrenchment takes forever to resolve moving forward with technological advance.

marcus

[toc] | [prev] | [next] | [standalone]

#67246

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 
> decimal.
> 
> Steven

Just a side note on how fast... Stefan Krah's performance specs state 120x improvement on many multiplication computations (like PI for instance)...  well, its not hype.

On my P7350 dual core 2Ghz Intel box (2009 mac mini) running Gnu/Linux, I used the piagm(n) AGM routine from my dmath.py library to benchmark against my own C routines, BC, and a couple of other math packages.  The results were phenomenal...  my processor is a low-end gem as compared to modern SOTA processors out there, and even yet:

 1 million digits of PI ---  13 minutes
10 million digits of PI ---  3 hours  55 minutes

Those were new digit/time PRs for me, by-the-by...   and the other methods I've used don't even come close...  so,  Stefan is doing some kind of transform in "decimal" over and above just compiling the extension in C  that is really speeding things up quite a bit.

(that was just a random side note, sorry)

[toc] | [prev] | [next] | [standalone]

#67247

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 
> 
> > for binary floats. Say, 0.1b if you want a binary float, and 0.1 for a 
> 
> > decimal.
> 
> > 
> 
> > Steven
> 
> 
> 
> Just a side note on how fast... Stefan Krah's performance specs state 120x improvement on many multiplication computations (like PI for instance)...  well, its not hype.
> 
> 
> 
> On my P7350 dual core 2Ghz Intel box (2009 mac mini) running Gnu/Linux, I used the piagm(n) AGM routine from my dmath.py library to benchmark against my own C routines, BC, and a couple of other math packages.  The results were phenomenal...  my processor is a low-end gem as compared to modern SOTA processors out there, and even yet:
> 
> 
> 
>  1 million digits of PI ---  13 minutes
> 
> 10 million digits of PI ---  3 hours  55 minutes
> 

Oh, rats(), I forgot the comparison....

Py3.2 [ 1 million digits : 21 hours 21 minutes ] --> Py3.3.4 [ 1 million digits : 13 minutes ]

    ...  that is astounding.   All I did was install  3.3.4,  no change in the AGM routine.

Cheers

[toc] | [prev] | [next] | [standalone]

#67159

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 am now looking at enhancement issues.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#67301

Terry Reedy <tjreedy@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
> bugs, but I hit them seldom enough that I am now looking at
> enhancement issues.

I recently watched a presentation by Jessica McKellar of PSF about what
Python needs to stay popular. Other than the obvious bits (difficulties
or limited support of Python on major platforms like Windows and mobile)
the slight lack of perfection in IDLE was mentioned. Specifically the
old blog post titled "The Things I Hate About IDLE That I Wish Someone
Would Fix" at
http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/

It lists 17 issues and some more in the comments. Are those things
something that could be considered? Or have maybe been done already? I'm
not an IDLE user so this is mostly an academic interest on my part.

[toc] | [prev] | [next] | [standalone]

#67396

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 lack of perfection in IDLE was mentioned. Specifically the
> old blog post titled "The Things I Hate About IDLE That I Wish Someone
> Would Fix" at

> http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/

hi Anssi,  this discussion really doesn't belong in this thread, but I'll give you my two cents
on it anyway, just because I put the random comment in here to begin with.

The blog link which you posted is quite old, and yes, as I remember back to the 2009-2011 time
frame IDLE had some problems with stability and some other issues related to tkinter. My experience 
with IDLE today is one of stability usefulness; clean and simple.

Like that FORD commercial here in the States, " Have you driven and IDLE lately?"

Some of the bloggers 'hates' are actually features of IDLE and we really don't want to change them. Some of them have been fixed. Some of them are annoyances not with IDLE per se, but with tcl/tk 
and are a tkinter thing. For instance, the blogger 'hates' the menu tear-off feature. I love it. All of my 
tcl/tk apps have tear-off menus; its totally a tkinter thing and if you're not used to apps written with
the tk library then this 'feature' may annoy you.

The IDLE concept was to have an IDE written in pure python that would use the tk library. If you've not written any code using the tk library then try it. GUI apps can be built with the tk library (with either tcl, or with python, and others) that are reduced to a few lines of code vs. many pages of code. In two pages of tk coding I can create a GUI app that would use 16 pages of code written in C, and 8-16 pages of code written in C++ or Java. The down-side to the tk library is that the GUI work they do for you under
the covers (which is extensive by the way) makes some assumptions and simplifies the options. So, 
you trade off the speed and efficiency of writing the app and getting it to market quickly, with not 
having the explicit control over the GUI that you might have if you had written the code to Q, or GTK,
or some such.

Producing IDLE using tk was genius on the part of Guido initially. The tradition has been kept up, but
has not received the priority that other python issues have received. By the way, there are other  python
IDEs out there (I don't use them, just pointing out that they are available). 

IDLE is free, its efficient, and for the moment its also very stable and highly useful. If you have not
driven an IDLE lately, give it a try. Also, my experience with the devs on IDLE (and particularly Terry Reedy) is that they have been very responsive, helpful, even courteous and professional. So, I think the
blogger was a little too harsh. 

Cheers

[toc] | [prev] | [next] | [standalone]

#67160

On Fri, Feb 28, 2014 at 4:07 AM, Terry Reedy <tjreedy@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 feedback. There are still some bugs, but
> I hit them seldom enough that I am now looking at enhancement issues.

Aside from having to be careful not to paste in a non-BMP character (a
Tk limitation, I believe, and currently being tracked at issue 13153),
I'm pretty happy with IDLE too. It's my standard way to fiddle with
Python code. Easier to use than the inbuilt interactive mode, as Alt-P
will recall an entire block command, rather than one line at a time.

So, I echo that sentiment of thanks. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#66724

On Wed, Feb 19, 2014 at 4:10 PM, Terry Reedy <tjreedy@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 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 noting
> in such a posting that Krah's speedup make such functions really feasible.
> The algorithms could be similar, at least initially, to the one used for
> floats.

It might be good to even go a step further, and make it "amath" (or
"numbers.math", or ...), a type-agnostic math module.  Such a module
would likely be slower than math, cmath, or "dmath", but should end
the proliferation of math modules.

-- 
Zach

[toc] | [prev] | [next] | [standalone]

#66731

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
> the moment, and wrapping python are the math routines for control and
> processing is so much better.   Anyway, sure would be nice to have a very
> speedy atan() function built-in for decimal.
> 

Have you looked at the gmpy2 ( https://code.google.com/p/gmpy/ ) module?

It supports all the transcendental function available in the MPFR library. I
did a quick performance test of sqrt() and ln() at around 1000 decimal digits.
gmpy2 was about ~200 times faster than the corresponding functions in decimal.

casevh

[toc] | [prev] | [next] | [standalone]

#67130

> 
> 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 multiplication at least...  but, as Oscar pointed out a native python series algorithm runs right along with the built-in  (at least for exp() and ln() )   I have not looked at Krah's code, so not sure what he did to speed things up... (something more than just writing it in C I would suppose).

Thanks for the heads up on gmpy

[toc] | [prev] | [next] | [standalone]

#67221

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 for ln() and sqrt().

> I was hoping that Stefan Krah's C accelerator was using FFT fast fourier
> transforms for multiplication at least...  
> .. snip ..
> I have not looked at Krah's code, so not sure what he did to speed things
> up... (something more than just writing it in C I would suppose).

IIRC, cdecimal uses a Number Theory Transform for multiplication of very large
numbers. It has been a while since I looked so I could be wrong.

casevh

[toc] | [prev] | [next] | [standalone]

#66725

On 19 February 2014 15:30, Mark H. Harris <harrismh777@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 searching of the pep history and I'm not finding any pep related to extending the decimal module with other scientific functions.

As Terry has pointed out, the decimal module follows IEEE 854 which
doesn't include those.

I think the module sort of has two big use-cases. On the one hand you
have people looking to do financial calculations etc. who are looking
for basic arithmetic with decimal type rounding. On the other hand you
have people like me who see it as a convenient multi-precision library
for when double precision just isn't enough. The module doesn't fully
live up to my use-case because as you say it lacks support for
transcendental functions.

I think, though, that there's a case for having say a "dmath" module
that would export a similar interface to the math and cmath modules
but with functions that work with Decimals in full precision. Someone
has already created a pure Python version of this idea here:
https://code.google.com/p/dmath/

> It is easy to write them in pure python, of course, but I am interested in having the same performance boost with atan(), sin(), cos(), and exp() as I see with the rest of the decimal module on 3.3/  Is it possible anytime sooner than later?

Actually the performance difference isn't as big as you might think.
So given the following exponential function:

from decimal import Decimal, localcontext

e = Decimal('2.7182818284590452353602874713527')

def exp(x):
    '''
        >>> print exp(Decimal(1))
        2.718281828459045235360287471
        >>> print exp(Decimal(2))
        7.389056098930650227230427461
    '''
    # Work in slightly higher precision
    with localcontext() as ctx:
        ctx.prec += 2
        xi, xf = divmod(x, 1)
        # Use integer exponentiation
        yi = e ** xi
        # Now use the Maclaurin series for the fractional part
        lastyf = -1
        yf = 1
        n = 0
        fact = 1
        xfn = 1
        while yf != lastyf:
            lastyf = yf
            n += 1
            fact *= n
            xfn *= xf
            yf += xfn / fact
    # Downgrade precision
    return yi * yf

import doctest
doctest.testmod()


I get the following timings:
$ python3.3 -m timeit -s 'from decimal import Decimal as D;
d=D('0.123'); from tmp import exp' 'exp(d)'
10000 loops, best of 3: 32.3 usec per loop
$ python3.3 -m timeit -s 'from decimal import Decimal as D;
d=D('0.123'); from tmp import exp' 'd.exp()'
10000 loops, best of 3: 26.5 usec per loop

So the pure Python exponential function (using the C-accelerated
decimal module) weighs in at 32usec and the pure C version at 26usec.
The intensity of software arithmetic even in C is still dominating the
performance here. The difference becomes more noticeable as you
approach an integer value from below e.g. something like 24.9 but not
more than a factor of 2.

For comparison here's how it looks on the FPU (from Python's perspective):

$ python3.3 -m timeit -s 'd=0.123; from math import exp' 'exp(d)'
10000000 loops, best of 3: 0.149 usec per loop

So that's 2 orders of magnitude faster. It makes sense if you think
about it in terms of CPU instructions: on x87 there are about 5
instructions to call exp in (extended) double precision and takes
about 20-30 cycles (with the time dominated by the F2XM1 instruction).
The number of integer instructions required to compute the above with
the decimal module is massive in comparison.


Oscar

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web