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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#91653

Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk>:

>>>> Decimal('0.3')
> Decimal('0.3')
>>>> Decimal(0.3)
> Decimal('0.299999999999999988897769753748434595763683319091796875')

At first I thought I had never dealt with money in Python nor made use
of Decimal. Then I remembered I *did* deal with money in one program and
wondered how I handled it. Sure enough:

        newdistr[clubacct] = decimal.Decimal("%.2f" % amount)


Marko

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

#91795

On Monday, June 1, 2015 at 1:28:53 PM UTC+5:30, Laura Creighton 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.
> 
> If I ever get the time machine, I am going back in time and demand that
> floating point numbers be expressed as 12345:678 instead of 12345.678
> because it would save so much trouble.  Never has the adage 'It's not
> what you don't know, that bites you.  It's what you know that ain't so.'
> been more apt.
> 
> I have done much better in speaking about this topic to a bunch of
> incredulous people if you next explain that scientists really don't
> care about accuracy in their calculations.  (This will surprise them).
> Most scentific calculations have some real world measurement in them,
> and for most real world measurements, if you are getting even 5 digits
> of precision, you are doing really, really, well.  This means that
> scientists are going to be throwing away all the extra digits they get
> out a a floating point representation, so they don't have to care how
> accurate they are.  As long as their results are good in the first 5,
> it won't matter.  (Depending on time constraints, a review of
> significant figures -- what they are and what they mean is good here.)
> 
> It is really hard to get the concept of Decimal across to people who
> already have that concept in their mind, but think it is called Float.
> You have to first teach them that they don't know anything about Float
> and get them to reboot their brains before you can install this new
> knowledge.  Otherwise their brains will just overwrite your new knowledge
> with 'ah, just use a Float' as soon as you stop speaking.  Same day,
> even.
> 
> Laura

I'd say on the whole this *intention* is rightly directed.
Whether it would work in practice I am not sure.
You may like to look at haskell's defaulting mechanism which is about as
sophisticated as I have seen
https://www.haskell.org/tutorial/numbers.html [sect 10.4]
Basically: (the ':t' says give me the type of...)

Prelude> :t 4
4 :: Num a => a
Prelude> :t 1.0
1.0 :: Fractional a => a

What this says is that 4 is not an integer but any type that is in the Num class
Likewise 1.0 is not float but any of a family of 'Fractional' types.

Your ':' suggestion would work if Decimal and machine floats covered all needs.
Do you think that is possible/likely?
If not we would have to fall back to some 'defaulting' mechanism anyway.
[In all fairness while Haskell's default looks neat on paper it turns out to
be quite a nuisance in practice]

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

#91642

On Mon, Jun 1, 2015 at 5:58 PM, Laura Creighton <lac@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.
>
> If I ever get the time machine, I am going back in time and demand that
> floating point numbers be expressed as 12345:678 instead of 12345.678
> because it would save so much trouble.  Never has the adage 'It's not
> what you don't know, that bites you.  It's what you know that ain't so.'
> been more apt.

While I agree that there are problems with conflating float with "real
number", I don't know that decimal.Decimal is actually going to solve
that either; and using a colon as the decimal separator won't solve
anything (the world already has two - "." in the US and "," in Europe
- and adding a third with the same semantics of separating the
greater-than-unit from the sub-unit digits won't instantly give new
meaning to the way numbers are handled), so I would be whacking you
over the head when you invent that time machine XKCD 716 style.

decimal.Decimal() has its own peculiarities, ways in which it isn't
the same as real numbers, so what's really needed is a talk about both
of them (and fractions.Fraction for completeness) and how they all
have their uses. People need to grok that what computers do with
numbers is never quite what they're used to from grade school
(although it can be close; bignum integer arithmetic is pretty
reliable).

ChrisA

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

#91649

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@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.
>>
>> If I ever get the time machine, I am going back in time and demand that
>> floating point numbers be expressed as 12345:678 instead of 12345.678
>> because it would save so much trouble.  Never has the adage 'It's not
>> what you don't know, that bites you.  It's what you know that ain't so.'
>> been more apt.
>
>While I agree that there are problems with conflating float with "real
>number", I don't know that decimal.Decimal is actually going to solve
>that either; and using a colon as the decimal separator won't solve
>anything (the world already has two - "." in the US and "," in Europe
>- and adding a third with the same semantics of separating the
>greater-than-unit from the sub-unit digits won't instantly give new
>meaning to the way numbers are handled), so I would be whacking you
>over the head when you invent that time machine XKCD 716 style.

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

The problem is that they take one look at a floating point number,
and think they know what it is from childhood, and use it.  They
don't know any better.  The notion that computer languages have
homophones, and just as the moles you have on your face and the
moles that burrow in your garden and the moles that you make out
of stone as a pier or a breakwater, numbers can work this way in
computers is deep, deep, deep in the 'this cannot be possible'
mindset of people who are learning to use computers.

I argued that when Decimal went into Python it should be called Money
(with an alias for Decimal for those who aren't using it for money) again
so that the people who don't know any better are more likely to end
up in the right place, but I lost that argument, too.

Laura

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

#91670

Laura Creighton <lac@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@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.

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

#91650

On 01/06/2015 08:58, Laura Creighton 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.
>
> If I ever get the time machine, I am going back in time and demand that
> floating point numbers be expressed as 12345:678 instead of 12345.678
> because it would save so much trouble.  Never has the adage 'It's not
> what you don't know, that bites you.  It's what you know that ain't so.'
> been more apt.
>
> I have done much better in speaking about this topic to a bunch of
> incredulous people if you next explain that scientists really don't
> care about accuracy in their calculations.  (This will surprise them).
> Most scentific calculations have some real world measurement in them,
> and for most real world measurements, if you are getting even 5 digits
> of precision, you are doing really, really, well.  This means that
> scientists are going to be throwing away all the extra digits they get
> out a a floating point representation, so they don't have to care how
> accurate they are.  As long as their results are good in the first 5,
> it won't matter.  (Depending on time constraints, a review of
> significant figures -- what they are and what they mean is good here.)
>
> It is really hard to get the concept of Decimal across to people who
> already have that concept in their mind, but think it is called Float.
> You have to first teach them that they don't know anything about Float
> and get them to reboot their brains before you can install this new
> knowledge.  Otherwise their brains will just overwrite your new knowledge
> with 'ah, just use a Float' as soon as you stop speaking.  Same day,
> even.
>
> Laura
>

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

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#91651

On Mon, Jun 1, 2015 at 8:28 PM, Laura Creighton <lac@openend.se> wrote:
> 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.  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.

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?

ChrisA

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

#91654

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

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

#91656

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

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

#91658

Laura Creighton <lac@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

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

#91662

On 01/06/2015 12:57, Marko Rauhamaa wrote:
> Laura Creighton <lac@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

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

#91663

On 2015-06-01 12:57, Marko Rauhamaa wrote:
> Laura Creighton <lac@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).

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

#91681

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

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

#91685

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

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

#91690

In a message of Mon, 01 Jun 2015 15:26:49 -0000, alister writes:
>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)

Interesting.  Somebody sent me one that supposedly was written for
then a few years ago.  Maybe it was doing 'old style accounting'
for fun?  I will have to go ask that person about it.  Thank you
for letting me know.

Laura

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

#91694

On 2015-06-01 16:51, Laura Creighton wrote:
> In a message of Mon, 01 Jun 2015 15:26:49 -0000, alister writes:
>> 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)
>
> Interesting.  Somebody sent me one that supposedly was written for
> then a few years ago.  Maybe it was doing 'old style accounting' for
> fun?  I will have to go ask that person about it.  Thank you for
> letting me know.
>
1971 was also the year we started the switch over to the metric system.
It was going to be done gradually over a 10-year period. It's still a
work in progress...

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

#91697

MRAB <python@mrabarnett.plus.com>:

> 1971 was also the year we started the switch over to the metric
> system. It was going to be done gradually over a 10-year period. It's
> still a work in progress...

Same here in Finland. Minutes, hours and degrees persist as do calories,
teaspoons and carats.


Marko

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

#91688

On 01/06/2015 16:07, 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.

Strangely I don't remember that. Although we did have to add up sums of 
money in three columns: pounds, shillings and pence, and carried as 
necessary from right to left.

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

You mean 12 pence or 20 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.

When decimal currency came in, we had decimals *and* fractions! Because 
of the 1/2p coin. So this didn't quite work.

But it can work now, so we have no need of either binary or decimal 
floating point.

(Well, until you have to work in dual currencies which can mean that an 
amount of money that is exact in one currency, can only be approximate 
in the other, when both are expressed in the smallest currency unit - 
cent, penny or whatever.)

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

At one time the choice was integer or floating point in many languages, 
unless you were specifically using a business language such as Cobol.

I think the Sinclair computer barely had integer types so the choice was 
even narrower.

-- 
Bartc

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

#91693

On 2015-06-01, BartC <bc@freeuk.com> wrote:

> At one time the choice was integer or floating point in many languages, 
> unless you were specifically using a business language such as Cobol.

My recollection in the early days of home computers is that many BASIC
implementations had BCD floating point instead of binary.  Back then
most CPUs had instructions specifcally for dealing with BCD
represented with 4-bits per digit.  Dunno if they still do, I can't
even remember the last time I did calculations in BCD.

> I think the Sinclair computer barely had integer types so the choice
> was even narrower.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm totally DESPONDENT
                                  at               over the LIBYAN situation
                              gmail.com            and the price of CHICKEN
                                                   ...

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

#91703

On 01/06/2015 18:02, Grant Edwards wrote:
> On 2015-06-01, BartC <bc@freeuk.com> wrote:
>
>> At one time the choice was integer or floating point in many languages,
>> unless you were specifically using a business language such as Cobol.
>
> My recollection in the early days of home computers is that many BASIC
> implementations had BCD floating point instead of binary.  Back then
> most CPUs had instructions specifcally for dealing with BCD
> represented with 4-bits per digit.  Dunno if they still do, I can't
> even remember the last time I did calculations in BCD.
>
>> I think the Sinclair computer barely had integer types so the choice
>> was even narrower.
>

Didn't Turbo C have compiler options to allow either BCD or fp?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

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

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

csiph-web