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

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

What is considered an "advanced" topic in Python?

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

Contents

  What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 09:01 -0700
    Re: What is considered an "advanced" topic in Python? Joel Goldstick <joel.goldstick@gmail.com> - 2015-05-29 12:08 -0400
      Re: What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 09:55 -0700
    Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-30 02:09 +1000
      Re: What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 09:57 -0700
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-30 03:08 +1000
        Re: What is considered an "advanced" topic in Python? random832@fastmail.us - 2015-05-31 23:18 -0400
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-01 13:43 +1000
        Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 09:58 +0200
          Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 12:36 +0300
            Zero [was Re: What is considered an "advanced" topic in Python?] Steven D'Aprano <steve@pearwood.info> - 2015-06-01 22:07 +1000
              Re: Zero [was Re: What is considered an "advanced" topic in Python?] Laura Creighton <lac@openend.se> - 2015-06-01 14:52 +0200
              Re: Zero [was Re: What is considered an "advanced" topic in Python?] Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-06-01 13:56 +0100
                Re: Zero [was Re: What is considered an "advanced" topic in Python?] Skip Montanaro <skip.montanaro@gmail.com> - 2015-06-01 08:14 -0500
                  Re: Zero [was Re: What is considered an "advanced" topic in Python?] Dave Farrance <df@see.replyto.invalid> - 2015-06-01 15:39 +0100
                Re: Zero [was Re: What is considered an "advanced" topic in Python?] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-01 18:35 +0100
                Re: Zero [was Re: What is considered an "advanced" topic in Python?] Terry Reedy <tjreedy@udel.edu> - 2015-06-01 17:32 -0400
              Re: Zero [was Re: What is considered an "advanced" topic in Python?] Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 16:18 +0300
                Re: Zero [was Re: What is considered an "advanced" topic in Python?] random832@fastmail.us - 2015-06-01 09:32 -0400
          Re: What is considered an "advanced" topic in Python? Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> - 2015-06-01 11:44 +0100
            Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 13:54 +0300
          Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-06-01 22:33 -0700
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-01 19:45 +1000
        Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 12:28 +0200
          Re: What is considered an "advanced" topic in Python? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-01 14:22 +0100
        Re: What is considered an "advanced" topic in Python? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-01 11:34 +0100
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-01 20:36 +1000
        Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 13:00 +0200
        Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 13:24 +0200
          Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 14:57 +0300
            Re: What is considered an "advanced" topic in Python? BartC <bc@freeuk.com> - 2015-06-01 13:27 +0100
            Re: What is considered an "advanced" topic in Python? MRAB <python@mrabarnett.plus.com> - 2015-06-01 13:27 +0100
            Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 17:07 +0200
              Re: What is considered an "advanced" topic in Python? alister <alister.nospam.ware@ntlworld.com> - 2015-06-01 15:26 +0000
                Re: What is considered an "advanced" topic in Python? Laura Creighton <lac@openend.se> - 2015-06-01 17:51 +0200
                Re: What is considered an "advanced" topic in Python? MRAB <python@mrabarnett.plus.com> - 2015-06-01 18:06 +0100
                  Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-06-01 20:14 +0300
              Re: What is considered an "advanced" topic in Python? BartC <bc@freeuk.com> - 2015-06-01 16:42 +0100
                Re: What is considered an "advanced" topic in Python? Grant Edwards <invalid@invalid.invalid> - 2015-06-01 17:02 +0000
                  Re: What is considered an "advanced" topic in Python? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-01 18:45 +0100
                    Re: What is considered an "advanced" topic in Python? Grant Edwards <invalid@invalid.invalid> - 2015-06-01 18:23 +0000
          Re: What is considered an "advanced" topic in Python? BartC <bc@freeuk.com> - 2015-06-01 13:24 +0100
        Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-01 23:52 +1000
          Re: What is considered an "advanced" topic in Python? BartC <bc@freeuk.com> - 2015-06-01 16:17 +0100
            Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-06-02 02:10 +1000
              Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-06-01 21:46 -0700
    Re: What is considered an "advanced" topic in Python? Skip Montanaro <skip.montanaro@gmail.com> - 2015-05-29 11:39 -0500
      Re: What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 09:58 -0700
    Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-30 02:50 +1000
    Re: What is considered an "advanced" topic in Python? Todd <toddrjen@gmail.com> - 2015-05-29 19:02 +0200
    Re: What is considered an "advanced" topic in Python? sohcahtoa82@gmail.com - 2015-05-29 10:03 -0700
      Re: What is considered an "advanced" topic in Python? Ethan Furman <ethan@stoneleaf.us> - 2015-05-29 10:17 -0700
        Re: What is considered an "advanced" topic in Python? sohcahtoa82@gmail.com - 2015-05-29 14:06 -0700
          Re: What is considered an "advanced" topic in Python? Jason Swails <jason.swails@gmail.com> - 2015-05-29 17:28 -0400
          Re: What is considered an "advanced" topic in Python? Ethan Furman <ethan@stoneleaf.us> - 2015-05-29 14:39 -0700
          Re: What is considered an "advanced" topic in Python? Ethan Furman <ethan@stoneleaf.us> - 2015-05-29 14:44 -0700
      Re: What is considered an "advanced" topic in Python? Marko Rauhamaa <marko@pacujo.net> - 2015-05-29 20:24 +0300
    Re: What is considered an "advanced" topic in Python? Todd <toddrjen@gmail.com> - 2015-05-29 19:03 +0200
    Re: What is considered an "advanced" topic in Python? Steven D'Aprano <steve@pearwood.info> - 2015-05-30 03:55 +1000
      Re: What is considered an "advanced" topic in Python? Mike Driscoll <kyosohma@gmail.com> - 2015-05-29 13:38 -0700
    Re: What is considered an "advanced" topic in Python? Sturla Molden <sturla.molden@gmail.com> - 2015-05-30 12:15 +0000
    Re: What is considered an "advanced" topic in Python? jonathon <jonathon.blake@gmail.com> - 2015-05-30 19:32 +0000
    Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-31 08:24 +1000
    Re: What is considered an "advanced" topic in Python? "C.D. Reimer" <chris@cdreimer.com> - 2015-05-30 18:28 -0700
    Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-05-30 20:30 -0700
      Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-31 14:25 +1000
        Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-05-30 21:46 -0700
          Re: What is considered an "advanced" topic in Python? Chris Angelico <rosuav@gmail.com> - 2015-05-31 14:58 +1000
            Re: What is considered an "advanced" topic in Python? Rustom Mody <rustompmody@gmail.com> - 2015-05-30 22:18 -0700
    Re: What is considered an "advanced" topic in Python? Gene Heskett <gheskett@wdtv.com> - 2015-06-01 09:49 -0400
    Re: What is considered an "advanced" topic in Python? Denis McMahon <denismfmcmahon@gmail.com> - 2015-06-01 15:30 +0000
    Re: What is considered an "advanced" topic in Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-06-01 20:33 -0400
    Re: What is considered an "advanced" topic in Python? Gene Heskett <gheskett@wdtv.com> - 2015-06-01 23:30 -0400

Page 4 of 4 — ← Prev page 1 2 3 [4]

#91529

Mike Driscoll <kyosohma@gmail.com> wrote:
> Hi,
> 
> I've been asked on several occasions to write about intermediate or
> advanced topics in Python and I was wondering what the community
> considers to be "intermediate" or "advanced". I realize we're all growing
> in our abilities with the language, so this is going to be very
> subjective, but I am still curious what my fellow Python developers think about this topic.

Coroutines, metaclasses and decorators is probably high up on the obscurity
list. Writing C extension modules is high up there as well, not to mention
embedding Python and using subinterpreters.


Sturla

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

#91540

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/05/2015 16:01, Mike Driscoll wrote:

>I was wondering what the community considers to be "intermediate" or "a
dvanced".

A python script that compiles python code.

jonathon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVahA4AAoJEE1PKy9+kxplmwsP/R4wkjcgYZwG8wHj6Jp2Do4C
+y3raHDA7PNko9Y/HSsIr3aXyXm9Yy71px3HDYkOXXsD3aO+GXUS14RbQXynK7OX
95LD+S0U9AtJL5Jlywmvm/QJQw6UuGnPfQSs2Y1HiALjlvZYCDMvoycvT4GY4+oQ
6n4tq/3ExdP1inxcu0CwMm7ZL7CCvvy1S7JkVdr+r13BM4TlXCRH9BAvJNtLnbtA
SvP5iOYRkOTvxYOw8veiKXD1clXK2fy3x4SjBtWpK0XZKSu2akWwlD0qvbVkf9qz
/Cu9aP3BbV4VSzLFkOEKU6b4NoZK1Al3s3e4IVvAjPSWIXI5LsKwuVrqvVZ+06Uv
u0ZYyX/4fnpmKaJXvAMyRWULNA+pDaqvjBGgom3qtvT2i8nfYN1KBkMBMrG/ioXt
4BUkAMhOqRHvsPHT+GXrtVaj5wFj1Q9i174CMfINLelbmUlpNhOTLzobm2hnwD/c
hZAVsDUzAxAQjLYNDQV+AtE2Cw4D0YKUJfILE1T82CerSnibjy3Z60RZ703e5oRU
pa75Fm8HpjAmNS4tbvENSz0v0VH6howH1gQdqc2bVzKBGj9ArXiA8yByxRgZdVwI
vXJMzxzpMBL35ScYBhvVPnD0zroa8WBYgrhTWVJFFJpk+eTjUetalTrvkTFYWgQ+
QLsCw9+wUjX8kVJ8Yhx6
=wU1w
-----END PGP SIGNATURE-----

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

#91546

On Sun, May 31, 2015 at 5:32 AM, jonathon <jonathon.blake@gmail.com> wrote:
> On 29/05/2015 16:01, Mike Driscoll wrote:
>
>>I was wondering what the community considers to be "intermediate" or "a
> dvanced".
>
> A python script that compiles python code.

What do you mean by "compiles"? Something as simple as an import
statement or exec call will compile arbitrary Python code, but if that
were what you meant, you'd have said "the exec() function". (The
implementation of namedtuple uses exec, and I think that would
definitely count as "advanced".) Or do you mean compiling to AST and
exploring the AST? That's a fairly reasonable intermediate topic,
though again, if that's what you meant, I'm sure you would have worded
it differently. The only other form of compilation I can think of is
going to an executable binary (the way a C compiler does), and that's
some serious work. I don't think PyPy is small enough to be called a
"script". :)

ChrisA

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

#91556

On 5/29/2015 9:01 AM, Mike Driscoll wrote:
> I've been asked on several occasions to write about intermediate or advanced topics in Python and I was wondering what the community considers to be "intermediate" or "advanced".

I'm trying my hand at Cython (http://cython.org/). I just know enough of 
the Python and C languages to understand the book, "Cython" by Kurt W. 
Smith, but trying to understand this on a deeper level by re-reading 
each chapter two or three times is enough to give me a headache.  Which 
is fine since I have no use for a programming book that I can breeze 
through. Then again, maybe this book wasn't the best book to learn 
Cython from.

Chris R.

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

#91559

On Friday, May 29, 2015 at 9:32:06 PM UTC+5:30, Mike Driscoll wrote:
> Hi,
> 
> I've been asked on several occasions to write about intermediate or advanced topics in Python and I was wondering what the community considers to be "intermediate" or "advanced". I realize we're all growing in our abilities with the language, so this is going to be very subjective, but I am still curious what my fellow Python developers think about this topic.

[I will assume that this question makes sense in the context of introducing
someone (say beginner/learner/noob/etc) to the language]
The zen of python makes a subtle distinction between complex and complicated.
The answers seem to suggest that people are taking the complicated for the complex.

So at the risk of being simplistic (or glib) let me give a definition and a fact:
Def:
Complex is an 'act of God'
Complicated is a slip of man

Fact:
Programming languages (like programs) are made by humans... who err.

So while the err-ors of programmers are only too well-known and spelt 'bugs'
we dont spend enough time on language-bugs.
In a teaching context this only does injustice to the student because the 
learner -- typically a kid -- suffering something or other and wondering
"Am I not fit for this?? Its so hard!" etc may only need a simple:
"Yeah the language designer goofed of on that one"

Trivial example:
C originally had only & | for both bitwise and logical operators.
Later the shortcircuit operators && || were added and kept adjacent in the
precedence table. MISTAKE.
The bitwise operators are conceptually arithmetic not logical, in that
x & MASK == MASK
can make sense only one way.
C makes sense of it the other way.

And so...
The most useful, honest line for a teacher to take is:
C has goofed on that one... So you need to parenthesize that
IOW the beginner is not wrong in writing
x & MASK == MASK
It is C that is wrong in choosing a meaningless parse of that

Now in all fairness python has less gotchas than C but it has its share.
So to my mind Steven's "iterators and generators" as intermediate represents 
no so much an inherent complexity of the subject as an unfortunate complication
from sub-optimal design.

I would put generators as basic; iterators as intermediate.
The generator
def foo():
  yield 1
  yield 2
  yield 3

is 'just' the list [1,2,3] + laziness - memoization and should be closer
to lists in dificulty-level than to iterators.

The reason it seems to be at the level of iterators is related to language
definition, documentation, ontology eg the 'fact' that foo looks like a function
when conceptually/ontologically/implementationally it is not.

This is a language-goofup not student ignorance

One more minor nit with Steven's intermediate-list:
Command line parsing with optparse/argparse.
Well if you use an obese library you get what you ask.
Whats wrong with getopt?
Seems to me simple enough for a beginner to write simple scripts

As I said this is a little nit.
However the pedagogic principle is important.
argparse may be recommended whereas getopt may be deprecated [dunno if it is]
Nevertheless pedagogic expedience is not the same as real world best practice.

<Admission>
In a recent course I taught, I used a[0] and a[1:] to split arrays and write
recursive functions a la Haskell in Python.
Is it efficient? no
Is it idiomatic python? NO!
Is it good to do that? That depends on one's priority.
In mine, learning recursion is more important than learning idiomatic python
</Admission>

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

#91560

On Sun, May 31, 2015 at 1:30 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> <Admission>
> In a recent course I taught, I used a[0] and a[1:] to split arrays and write
> recursive functions a la Haskell in Python.
> Is it efficient? no
> Is it idiomatic python? NO!
> Is it good to do that? That depends on one's priority.
> In mine, learning recursion is more important than learning idiomatic python
> </Admission>

If recursion is more important than idiomatic Python, why are you
using a Python interpreter? Use Python to teach Python, and use
Haskell to teach Haskell!

ChrisA

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

#91561

On Sunday, May 31, 2015 at 9:55:45 AM UTC+5:30, Chris Angelico wrote:
> On Sun, May 31, 2015 at 1:30 PM, Rustom Mody wrote:
> > <Admission>
> > In a recent course I taught, I used a[0] and a[1:] to split arrays and write
> > recursive functions a la Haskell in Python.
> > Is it efficient? no
> > Is it idiomatic python? NO!
> > Is it good to do that? That depends on one's priority.
> > In mine, learning recursion is more important than learning idiomatic python
> > </Admission>
> 
> If recursion is more important than idiomatic Python, why are you
> using a Python interpreter? Use Python to teach Python, and use
> Haskell to teach Haskell!

Heh! I would have expected less naivete from you Chris!
Firstly idiomatic haskell is as low priority (maybe more so) than idiomatic python

More to the point no language matches perfectly¹ everything that a learner needs to learn.
Can you write a kernel module in python? (Or Haskell?)
Can you see details of machine state and transitions in python?
Can you client-script a browser in python?
C is the best fit for the first
Assembly for the second
Javascript for the third.

And probably a dozen other languages for a dozen other key concepts.

Finally the idiomatic vs fundamentals is not a clear binary divide.
If I were interviewing someone claiming to be a C programmer who did not know
the difference between postfix and prefix ++, I'd be darned suspicious.
OTOH if someone who had written significant code in C simply refused to write
a '++' saying "Causes just too much trouble" most people would regard it as odd
but not unacceptable.

¹ or can. Thats Gödel's second theorem for you

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

#91562

On Sun, May 31, 2015 at 2:46 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> More to the point no language matches perfectly¹ everything that a learner needs to learn.
> Can you write a kernel module in python? (Or Haskell?)
> Can you see details of machine state and transitions in python?
> Can you client-script a browser in python?
> C is the best fit for the first
> Assembly for the second
> Javascript for the third.

And if I want to build a web site, I won't write assembly code using
Python idioms. I will use Python. Why fight against a language?

ChrisA

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

#91563

On Sunday, May 31, 2015 at 10:28:39 AM UTC+5:30, Chris Angelico wrote:
> On Sun, May 31, 2015 at 2:46 PM, Rustom Mody wrote:
> > More to the point no language matches perfectly¹ everything that a learner needs to learn.
> > Can you write a kernel module in python? (Or Haskell?)
> > Can you see details of machine state and transitions in python?
> > Can you client-script a browser in python?
> > C is the best fit for the first
> > Assembly for the second
> > Javascript for the third.
> 
> And if I want to build a web site, I won't write assembly code using
> Python idioms. I will use Python. Why fight against a language?

I thought I answered. I try again...
Because its the law.
Why does iron rust?
Why do cars/rockets not go faster than light?
Why do we age/shrivel/wither/die?
Because thats the law.
The law here is Gödel's second theorem -- no single formalism can encompass all
formalisms.
Any real solution to a significant problem will use some (set of) languages
which will fit good here and not so good there.
Square pegs in round holes are not ideal
Yet every so often there's no choice but to use a wrench to hammer a screw 
through a brick.

The C/assembly/javascript were extreme black-n-white examples.
Most real cases are more fuzzy.
Linus Torvalds thinks C++ (both the language and programmers) consititute
an asinine choice for writing kernel-code.
I am ready to bet that a democratic election on the subject will leave Torvalds
trailing.  ie the world's C++ programmers likely disagree with him.

Who is right?
Ive no idea. Do you?

The main point lost in this discussion is "What is the point?"
If you ask a beginner to write a function to give fibonacci numbers,
are fibonacci numbers the point?

I dont believe that python is 'the point' much more than fibonacci numbers.

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

#91675

On Monday 01 June 2015 07:24:52 Laura Creighton wrote:
> In a message of Mon, 01 Jun 2015 20:36:14 +1000, Chris Angelico writes:
> >The problem isn't the decimal separator, though, because floats can
> >have problems even without it (and can have no problems with a
> > decimal separator). If you want to distinguish "computer numbers"
> > from "real numbers", you'd do better to pick a different set of
> > symbols for them - or at least a different numerical base. If all
> > literals were written in octal, people would understand that there's
> > something special going on here. But would that really help?
>
> Maybe _your_ brain needs some resetting, too. :)  You know too much so
> have lost the grasp of how the world looks to the new programmer.
>
> Problem:
> I want to use a computer to add up a whole lot of money amounts so I
> can figure out how much money to send some place.
>
> This is an absolute, dead simple first computer program newbies write.
> For a lot of people, this used to be the whole reason they bought a
> computer in the first place.  Now they just want to do the same stuff
> on their phone, which they have anyway.
>
> And they immediately grab floating point numbers, and since adding
> a whole lot of them in range of 'prices for stuff at the supermarket'
> is one of the best ways to guarantee your will not get the correct,
> exact amount you want for your answer, they don't get it.
>
> You can pick any representation you want for float, as long as it
> _isn't_ the same one as we use for money, and a whole lot of problems
> will go away.  Because the problems are in the users' heads, and
> no place else, and the problem is 'This looks familiar.  I will use it
> an expect it to behave like I am used to.'  All human beings do this
> all the time, so the way to prevent the problem is to make it look
> less familiar.  But way back in time, you know.  Von Neumann
> recommended against floating-point numbers for the 1951 IAS machine,
> arguing that fixed-point arithmetic is preferable.  I agree, but, if
> John von Neumann couldn't win that argument, then there is no way on
> earth I could. So, if floating point is going in, at least we should
> represent them differently.
>
> But I am a bad arguer.
>
> When incompatibilites were going into Python 3.0 I wanted
>
> y = 1.3  to give you a decimal, not a float.
>
> If you wanted a float you would have to write y = 1.3f or something.
>
> I lost that one too.  I still think it would be great.
>
> But, hell, I write accounting and bookkeeping systems.  Your milage
> may vary. :)
>
> Laura

I may have gotten stoned and missed it, as I am not yet that familiar 
with python, which is why I am lurking on this list, hoping to absorb 
some of it by osmosis.

But IMO, any language that does not have the ability to set an fp number 
to a fixed number of digits to the right of the separator regardless of 
which , or . is used, needs one written.

The ability to guarantee that the output of a FIX(2) is zero to at least 
17 significant digits so that a zero coomparison is not non-zero because 
theres a 1 15 digits out in a 2 digit money format, is an absolute 
requirement.

I also write G-Code for cnc machinery, and that is something that is 
missing from common usage in most implementations of RS-274D, so we have 
to specifically set the seed value of the variables we use to 8 or more 
digits to the right of the decimal point.  Typically the machine can do, 
if calibrated correctly, cuts to .00025 inch accuracy, and to have to 
specify to fractions of an angstrom in order to make a while statement 
function as desired can be a gotcha.  I am used to it, so I do it 
automatically now, but it still bites the new bee getting started.

So teach me the error of my thinking.  Surely python has such a function.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#91686

On Fri, 29 May 2015 09:01:55 -0700, Mike Driscoll wrote:

> I've been asked on several occasions to write about intermediate or
> advanced topics in Python and I was wondering what the community
> considers to be "intermediate" or "advanced". I realize we're all
> growing in our abilities with the language, so this is going to be very
> subjective, but I am still curious what my fellow Python developers
> think about this topic.

Hmmm, in terms of learning about computer programming:

simplest: print "hello world"

then things get more advanced in steps:

(1) more instructions, but executed linearly, numbers and strings.

(2) conditional execution - if statement (including error trapping)

(3) loops, lists, dictionaries

(4) defining functions

(5) recursion

(6) sexy python stuff - things like list comprehensions, using iterators, 
importing modules etc

I think that's probably "basic python" covered in 6 steps (7 if you 
include hello world). Although you now have all the tools you need to 
write python code to do possibly very complex tasks, and thus to write 
very complex programs, you're using (IMO) basic python programming skills 
in doing so.

I guess that makes OOP / classes the advanced topic in my system.

I don't consider "using library x to do y" as advanced python, it's just 
gluing together existing functions with your own basic programming, no 
matter whether the library is for hardware IO, interfacing to a database 
etc.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#91738

On Mon, 1 Jun 2015 09:49:35 -0400, Gene Heskett <gheskett@wdtv.com>
declaimed the following:


>But IMO, any language that does not have the ability to set an fp number 
>to a fixed number of digits to the right of the separator regardless of 
>which , or . is used, needs one written.
>
	That removes all modern hardware units using IEEE floating point
standard, and pretty much all languages since (including) the first version
of FORTRAN.

	Floating point numbers are x-significant digits (commonly x:7 for
single precision and x:15 for double precision) with an exponent.

	Ada supports float and fixed point, but fixed point most easily
visualized as an integer with a scaling factor.

>The ability to guarantee that the output of a FIX(2) is zero to at least 
>17 significant digits so that a zero coomparison is not non-zero because 
>theres a 1 15 digits out in a 2 digit money format, is an absolute 
>requirement.
>
	Use COBOL then... One used to have to go out of their way to get a
"floating point" data type in COBOL... The common numeric type is packed
BCD.

	Even M$ "money" datatype uses four decimal places even if only two are
displayed to the user -- it allows for accumulation of fractions of a cent
over time.


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#91777

On Monday 01 June 2015 20:33:50 Dennis Lee Bieber wrote:
> On Mon, 1 Jun 2015 09:49:35 -0400, Gene Heskett <gheskett@wdtv.com>
>
> declaimed the following:
> >But IMO, any language that does not have the ability to set an fp
> > number to a fixed number of digits to the right of the separator
> > regardless of which , or . is used, needs one written.
>
> 	That removes all modern hardware units using IEEE floating point
> standard, and pretty much all languages since (including) the first
> version of FORTRAN.
>
> 	Floating point numbers are x-significant digits (commonly x:7 for
> single precision and x:15 for double precision) with an exponent.
>
> 	Ada supports float and fixed point, but fixed point most easily
> visualized as an integer with a scaling factor.
>
> >The ability to guarantee that the output of a FIX(2) is zero to at
> > least 17 significant digits so that a zero coomparison is not
> > non-zero because theres a 1 15 digits out in a 2 digit money format,
> > is an absolute requirement.
>
> 	Use COBOL then... One used to have to go out of their way to get a
> "floating point" data type in COBOL... The common numeric type is
> packed BCD.
>
> 	Even M$ "money" datatype uses four decimal places even if only two
> are displayed to the user -- it allows for accumulation of fractions
> of a cent over time.
>
That is a far more restrictive interpretation than I had in mind.  What, 
in the case of g-code should be the result of looking at a double and 
seeing that rounding errors in incrementing a number origially set to 
zero adding 1.000 to it 21 times, have created say 21.00000001200873000. 
Then we do a 

while [number gt 0.000000]
number=number - 1.0000000
do stuff using that number
endwhile

But the loop then iterates an extra pass, because the 1200873000 is still 
there.  The numbers are all double's, but weren't initialized to a 
sufficient number of digits to the right of the . or ,

This is of course our own fault, caused by sloppy coding.  But specifying 
the value to 15 magnitudes more than the machine is capable of without 
spending weeks writing a screw compensation file to get that level of 
accuracy is counterproductive.  Its severe overkill IMO.  Any language 
ought to just throw away those rounding errors by filling the extra 
precision with NNNNN.nnnn000000000000000's. even if the original 
initialized value was only stated as 1.00000.


> --
> 	Wulfraed                 Dennis Lee Bieber         AF6VN
>     wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web