What is considered an "advanced" topic in Python?

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

Laura Creighton-2
In a message of Mon, 01 Jun 2015 11:34:08 +0100, Mark Lawrence writes:

>In the wonderful world of numbers I believe that things are looking up.
>  I don't recall a new issue on the bug tracker for several months along
>the lines of "Python can't do arithmetic properly".

How Great to Hear!  <cheer cheer cheer>

But I wonder how much of that has to do with changing division?

OpenEnd (my company) makes bookkeeping systems for Swedish Ideal
Societies (closest English words 'non-profits' and 'clubs').  A
surprising number of our potential customers are relying on code
written more than 20 years ago, by somebody who is no longer part of
the Society which used floats for arithmetic.  Hard to make the sale
when the customer thinks your math is broken. So I am biased, but in
my little corner of the world, Float Confusion Reigns Supreme.

Laura


Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

Laura Creighton-2
In reply to this post by Chris Angelico
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


Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

Marko Rauhamaa
In reply to this post by Chris Angelico
Laura Creighton <lac at openend.se>:

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

Your problem is not fixed-point vs floating-point but related to the
radix. Base-10 floating-point would be perfect for you and base-2
fixed-point would demonstrate even worse rounding errors.

> But, hell, I write accounting and bookkeeping systems.

Ah, I see.

In 1951, decimal numbers would have done little good in the UK with the
pound divided into 20 shillings and the shilling into 12 pence. Maybe a
"Babylonian" module would have been perfect.


Marko

Reply | Threaded
Open this post in threaded view
|

Zero [was Re: What is considered an "advanced" topic in Python?]

Steven D'Aprano-8
In reply to this post by Marko Rauhamaa
On Mon, 1 Jun 2015 07:36 pm, Marko Rauhamaa wrote:

> However, I constantly run into engineers who don't understand what
> zero means.

Okay, I'll bite.

What does zero mean, and how do engineers misunderstand it?



--
Steven


Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

BartC-3
In reply to this post by Chris Angelico
On 01/06/2015 12:24, Laura Creighton wrote:

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

Maybe the new programmer should learn then that binary floating point
might not perform as they might expect.

I'm sure it wasn't long after I first started programming that I
discovered the reason why code such as:

  for i:=0.0 until 10.0 step 0.1 ...     # (Algol 60)

might not always work properly.

I don't think using decimal magically solves all problems either:

  a=decimal.Decimal('0.0')
  b=decimal.Decimal('1.0')/decimal.Decimal('3.0')
  c=decimal.Decimal('10.0')

  while a<=c:
        print (a)
        a=a+b

This prints 9.999... as the final value rather than 10.0. And if changed to:

  while a!=c:
      .....

then this doesn't terminate.

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

How many people who buy phones are actually going to write their own
programs? Rather than download an app written by people who can code (or
use the built-in calculator). (How do you even code in Python on a
smartphone 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.

Also, how many items need to be added up before even 64-bit floating
point values show a discrepancy, after rounding to whole cents? Or are
we adding up billions of dollars and expecting a result to the exact cent?

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

1.3 yielding floating point is fairly universal. Probably there would be
bigger problems if 1.3 silently gave you a decimal type.

> But, hell, I write accounting and bookkeeping systems.  Your milage
> may vary. :)

You can emulate decimal floating point with binary floating point, if
the latter has some spare precision. Or an easy fix for the shopping
problem is to work in whole cents, using either integer or floating
point (although the latter limits you to some $50 trillion dollars for
the total, which might be a problem if we ever get hyper-inflation again).

But if the numeric representation is crucial to your application, then
surely you just create a custom type or class for that? (I think Python
is quite good at this sort of customising; I lot of Python code I see
now seems to consist of nothing else!)

--
Bartc


Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

BartC-3
In reply to this post by Marko Rauhamaa
On 01/06/2015 12:57, Marko Rauhamaa wrote:

> Laura Creighton <lac at openend.se>:
>
>> 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.
>
> Your problem is not fixed-point vs floating-point but related to the
> radix. Base-10 floating-point would be perfect for you and base-2
> fixed-point would demonstrate even worse rounding errors.
>
>> But, hell, I write accounting and bookkeeping systems.
>
> Ah, I see.
>
> In 1951, decimal numbers would have done little good in the UK with the
> pound divided into 20 shillings and the shilling into 12 pence.

And pence divided into farthings and half-pennies. (With certain
prestige goods prices in guineas (21 shillings) for good measure.)

--
Bartc


Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

MRAB-2
In reply to this post by Marko Rauhamaa
On 2015-06-01 12:57, Marko Rauhamaa wrote:

> Laura Creighton <lac at openend.se>:
>
>> 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.
>
> Your problem is not fixed-point vs floating-point but related to the
> radix. Base-10 floating-point would be perfect for you and base-2
> fixed-point would demonstrate even worse rounding errors.
>
>> But, hell, I write accounting and bookkeeping systems.
>
> Ah, I see.
>
> In 1951, decimal numbers would have done little good in the UK with the
> pound divided into 20 shillings and the shilling into 12 pence. Maybe a
> "Babylonian" module would have been perfect.
>
Don't forget that there was also a ha'penny (half-penny).


Reply | Threaded
Open this post in threaded view
|

Zero [was Re: What is considered an "advanced" topic in Python?]

Laura Creighton-2
In reply to this post by Steven D'Aprano-8
In a message of Mon, 01 Jun 2015 22:07:41 +1000, "Steven D'Aprano" writes:

>On Mon, 1 Jun 2015 07:36 pm, Marko Rauhamaa wrote:
>
>> However, I constantly run into engineers who don't understand what
>> zero means.
>
>Okay, I'll bite.
>
>What does zero mean, and how do engineers misunderstand it?
>
>
>
>--
>Steven

I assume he meant 0 padding for fast fourier transforms, but I could
be wrong about that, too.

Laura


Reply | Threaded
Open this post in threaded view
|

Zero [was Re: What is considered an "advanced" topic in Python?]

Dave Farrance
In reply to this post by Steven D'Aprano-8
Steven D'Aprano <steve at pearwood.info> wrote:

>On Mon, 1 Jun 2015 07:36 pm, Marko Rauhamaa wrote:
>
>> However, I constantly run into engineers who don't understand what
>> zero means.
>
>Okay, I'll bite.
>
>What does zero mean, and how do engineers misunderstand it?

There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.

Reply | Threaded
Open this post in threaded view
|

Zero [was Re: What is considered an "advanced" topic in Python?]

Skip Montanaro
On Mon, Jun 1, 2015 at 7:56 AM, Dave Farrance <
DaveFarrance at omitthisyahooandthis.co.uk> wrote:
> There are two hard things in computer science: cache invalidation, naming
things, and off-by-one errors.

So it's 1 that engineers really don't understand? Just add 1 and you get
the correct number of hard things. <wink>

Skip

P.S., Dave, your "omitthis" and "andthis" kind of sucks for the rest of us.
And I just invalidated your attempts at
obscurity by replying to your correct email address. I suggest you just
omit that stuff going forward. Unfortunately,
I now I have a crap address in my Gmail contacts I have to hunt down and
remove. Maybe you should just install
a decent spam filter <http://www.spambayes.org/> or switch to Gmail, which
has a functioning spam filter (unlike Yahoo...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150601/80e20074/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Zero [was Re: What is considered an "advanced" topic in Python?]

Marko Rauhamaa
In reply to this post by Steven D'Aprano-8
Steven D'Aprano <steve at pearwood.info>:

> What does zero mean, and how do engineers misunderstand it?

Off the top of my head:

 * Code that does:

      if elements:
          for element in elements:
              ...

   instead of:

      for elements in elements:
          ...

 * C++ insists that all objects have nonzero sizes. This program:

   ====================================================================
   #include <stdio.h>
   struct S {};
   int main()
   {
       printf("%zd\n", sizeof(struct S));
       return 0;
   }
   ====================================================================

   prints out 1 when compiled with c++ but 0 when compiled with cc.

 * In C, it used to be illegal to define a struct without a dummy field
   or a zero-length array. At one point, that created irritating trouble
   for compilers that generated C.

 * malloc(0) is allowed to return NULL as a successful return value
   inviting application programming errors. Calling free(NULL) didn't
   use to be guaranteed to work.

 * Numerous shell commands assign special meaning to zero arguments.
   For example:

      $ ls a b c
      a b c
      $ ls a b
      a b
      $ ls a
      a
      $ ls
      a b c d e f g

      $ ln -s a b c
      # creates two links under c, which must be a directory
      $ ln -s c
      # creates one link under .

 * Wild-card expansion always produces at least one result:

      for src in *.py; do
          # executed even in the absence of a .py file
      done

 * Python insists that a block contain at least one statement even
   though technically, it is not necessary for syntactic reasons. Not a
   biggie but can cause a minor annoyance when commenting out a line.

 * Numerous timer implementations take 0 to mean infinity. For example,
   in Java:

       public final void wait(long timeout)
                throws InterruptedException

       [...] If timeout is zero, however, then real time is not taken
       into consideration and the thread simply waits until notified.

       <URL: https://docs.oracle.com/javase/7/docs/api/java/lan
       g/Object.html#wait%28long%29>

   A nasty surprise for those who'd naively expect zero to mean zero,
   especially if zero is the result of downward rounding.


Marko

Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

Ben Bacarisse
In reply to this post by Chris Angelico
Laura Creighton <lac at openend.se> writes:

> In a message of Mon, 01 Jun 2015 19:45:31 +1000, Chris Angelico writes:
>>On Mon, Jun 1, 2015 at 5:58 PM, Laura Creighton <lac at openend.se> wrote:
>>> If you are giving a talk about Decimal -- and trying to stamp out the
>>> inappropriate use of floats you have to first inform people that
>>> what they learned as 'decimals' as children was not floating point,
>>> despite the fact that we write them the same way.

That may be focusing on the wrong aspect because what you learn in
school (at least in the UK) is not so dissimilar to floating point
arithmetic.  The differences between that and machine floating point are
that (a) machines typically use base 2 (so the set of fractions that can
be represented exactly is a surprise); (b) machines use fixed-size
floating point whereas at school the representation, whilst always
finite, is more elastic; and (c) the base you calculate in is the base
you are given the data in and also the base you have to give the result
in.

For example, when a pupil is asked to "calculate 1.5 x 10^3 + 1.01 x
10^2 to two decimal places" what they will do is very similar to what a
machine would do if it had decimal floating point.  The surprises that
come from using typical machine floating point come from two base
conversions and (possibly) from rounding at every stage rather than just
at the end.

<snip>
> You have missed my point.  What I want is for floats never to be
> represented as '.' or ',' notation.  That way, when each naive
> user writes his or her first program that deals with money, when
> they look at their computer manual they will come to the section on
> floating point numbers and they will all look like something they
> have never seen before.

I agree that the key in to learn enough about what is going on.  Maybe
the solution is to teach people fixed-width binary floating point
arithmetic in schools!

> So they will read the section carefully
> to see if this is what they want or need, and the section can nicely
> say NEVER USE THIS FOR MONEY and they will know they are in the wrong
> place.

I know what you mean by this but it still bothers me a bit!  My first
job was writing programs for an economist.  It was all about money but,
being macro economics, was all in floating-point.  (In those days you
could not solve sets of non-linear differential equations in reasonable
time using anything else, but even if you could there would be no
point.)

Even some kinds of accounting can be done using floating point.  You can
use "scaled integers" in floating point to get some advantages over
integer arithmetic.  You might get a wider range (~53 bits rather than
32 say) and you get very simple checks for many overflow conditions.
You can also arrange for a simple check that you've failed to round
correctly at some step -- any non-integer fractional part will usually
indicate this.

I'm not averse to a blanket warning as the simplest way to get the
message across to beginners, but it's slowly becoming a "fact" that
nothing to do with money can be done correctly using floating point.

<snip>
--
Ben.

Reply | Threaded
Open this post in threaded view
|

Zero [was Re: What is considered an "advanced" topic in Python?]

random832@fastmail.us
In reply to this post by Marko Rauhamaa
On Mon, Jun 1, 2015, at 09:18, Marko Rauhamaa wrote:
>       if elements:
>           for element in elements:
>               ...
>
>    instead of:
>
>       for elements in elements:

TypeError: 'NoneType' object is not iterable

Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

gene heskett-4
In reply to this post by Laura Creighton-2
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>

Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

Chris Angelico
In reply to this post by Laura Creighton-2
On Mon, Jun 1, 2015 at 9:24 PM, Laura Creighton <lac at openend.se> 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.
>
> And they immediately grab floating point numbers...

That part I do understand; floating-point is the one obvious way to do
these sorts of things. I'm fairly sure we agree that a novice *will*,
for better or for worse, stumble upon floats - in pretty much any
language.

The question is, what part of float is wrong? I don't think the
problem is with the decimal separator, and therefore laying them out
as "whole part, colon, fractional part" won't necessarily help. And it
can potentially hurt, by teaching people that computers are just
weird, and you have to speak a weird language to talk to them -
without understanding that there's a real difference behind this. It's
like the eternal debate about assignment and whether "x = x + 1" is
nonsense, with advocates preferring "x := x + 1" as being somehow
fundamentally different. It isn't. It's just a notational change, and
not even a huge one. (Though I do see the line of argument that it
should be "x <- x + 1" or something else that looks like an arrow.)

ChrisA

Reply | Threaded
Open this post in threaded view
|

Zero [was Re: What is considered an "advanced" topic in Python?]

Dave Farrance-2
In reply to this post by Dave Farrance
Skip Montanaro <skip.montanaro at gmail.com> wrote:

>P.S., Dave, your "omitthis" and "andthis" kind of sucks for the rest of us.
>And I just invalidated your attempts at
>obscurity by replying to your correct email address. I suggest you just
>omit that stuff going forward. Unfortunately,
>I now I have a crap address in my Gmail contacts I have to hunt down and
>remove. Maybe you should just install
>a decent spam filter <http://www.spambayes.org/> or switch to Gmail, which
>has a functioning spam filter (unlike Yahoo...)

I've had that as my Usenet address since 2000 when Usenet was the prime
spam harvesting source and the spammers were actively using
anti-address-munging techniques.  That's no longer so much of a problem,
given Usenet's obscurity for today's average Internet user, but I'm
still wary of posting email addresses directly to Usenet.  I've changed
the "from" address to end with ".invalid" which is the RFC way, and
should be stopped at the Email client, if that helps.

Since this is "comp.lang.python", I'm assuming that it should be treated
primarily as a Usenet group in which you'd normally reply to the group
-- rather than by personal email as you might do if this was primarily a
Listserv group.  I dunno what the group thinks about that.  A quick
header check tells me that the posters here are split about 50/50
between posting via Usenet or the list server.
 

Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

Laura Creighton-2
In reply to this post by Marko Rauhamaa
In a message of Mon, 01 Jun 2015 14:57:02 +0300, Marko Rauhamaa writes:
>In 1951, decimal numbers would have done little good in the UK with the
>pound divided into 20 shillings and the shilling into 12 pence. Maybe a
>"Babylonian" module would have been perfect.
>
>
>Marko

You are being facetious, but in point of fact, naive Brits who knew nothing
of neither accounting systems nor floating point for the most part got
things right when they bought their Sinclair computer in the early
1980s.

This is because their natural tendancy was to calculate all the pounds
separately, and then the shillings, separately, and then the pence.
(With Guineas and other odd stuff thrown in, when the needed them).
This meant that they kept 3+ legers at one time, and then, when they
were done calculating as one final step converted what they had into
its representation where you never had more than 100 pence or 12 shillings.
Thus, entirely by accident, they did their accounting in integers, not
decimals at all.

And this is, of course, the first thing that people who write real
systems that add money learn -- convert everything to pennies (or
whatever you call them) and do all your calculations in pennies, and
then as the final step express that in dollars and cents, or euros
and cents, or what have you.

The Brits still got in trouble when they needed to calculate things for their
4.2 per cent morgage, or decided to keep a running total of the sales
tax they were paying, but they at least did not grab the floating
number representation as the first thing off the shelf when they needed
money.

Laura

Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

BartC-3
In reply to this post by Laura Creighton-2
On 01/06/2015 14:52, Chris Angelico wrote:
 > It's
> like the eternal debate about assignment and whether "x = x + 1" is
> nonsense, with advocates preferring "x := x + 1" as being somehow
> fundamentally different. It isn't. It's just a notational change, and
> not even a huge one. (Though I do see the line of argument that it
> should be "x <- x + 1" or something else that looks like an arro'w.)

'x <- x + 1' already means something as an expression (whether x is less
than (-x+1). 'x <= x + 1' has the same problem.

But I have used "=>" before,  for left-to-right assignment. (Mostly I
use ":=")

--
Bartc



Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

alister
In reply to this post by Marko Rauhamaa
On Mon, 01 Jun 2015 17:07:18 +0200, Laura Creighton wrote:

> In a message of Mon, 01 Jun 2015 14:57:02 +0300, Marko Rauhamaa writes:
>>In 1951, decimal numbers would have done little good in the UK with the
>>pound divided into 20 shillings and the shilling into 12 pence. Maybe a
>>"Babylonian" module would have been perfect.
>>
>>
>>Marko
>
> You are being facetious, but in point of fact, naive Brits who knew
> nothing of neither accounting systems nor floating point for the most
> part got things right when they bought their Sinclair computer in the
> early 1980s.
>
> This is because their natural tendancy was to calculate all the pounds
> separately, and then the shillings, separately, and then the pence.
> (With Guineas and other odd stuff thrown in, when the needed them).
> This meant that they kept 3+ legers at one time, and then, when they
> were done calculating as one final step converted what they had into its
> representation where you never had more than 100 pence or 12 shillings.
> Thus, entirely by accident, they did their accounting in integers, not
> decimals at all.
>
> And this is, of course, the first thing that people who write real
> systems that add money learn -- convert everything to pennies (or
> whatever you call them) and do all your calculations in pennies, and
> then as the final step express that in dollars and cents, or euros and
> cents, or what have you.
>
> The Brits still got in trouble when they needed to calculate things for
> their 4.2 per cent morgage, or decided to keep a running total of the
> sales tax they were paying, but they at least did not grab the floating
> number representation as the first thing off the shelf when they needed
> money.
>
> Laura

I don't think anyone programmed a Sinclair computer to use pre-decimal
currency, we converted to decimal in 1971 (although the last pre-decimal
coin did not go out of use untill 1993)  



--
If I traveled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.
                -- Bert Whitney

Reply | Threaded
Open this post in threaded view
|

What is considered an "advanced" topic in Python?

Denis McMahon
In reply to this post by Mike Driscoll
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 at gmail.com

1234