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

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

Clean Singleton Docstrings

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

Contents

  Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-07 23:46 +0000
    Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-08 12:53 +1000
    Re: Clean Singleton Docstrings Michael Selik <michael.selik@gmail.com> - 2016-07-07 23:43 -0400
      Re: Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-08 16:57 +0000
        Re: Clean Singleton Docstrings Ethan Furman <ethan@stoneleaf.us> - 2016-07-08 13:00 -0700
    Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-08 09:38 +0200
      Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-08 19:20 +1000
        Re: Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-08 16:47 +0000
      Re: Clean Singleton Docstrings Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-13 15:42 -0700
        Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-14 01:54 +0200
          Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-15 21:04 -0700
            Re: Clean Singleton Docstrings Ethan Furman <ethan@stoneleaf.us> - 2016-07-15 21:20 -0700
              Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-15 22:51 -0700
              Re: Clean Singleton Docstrings Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-15 23:19 -0700
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-16 16:29 +1000
                Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-16 02:53 -0400
                  Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-16 18:54 +1000
                  Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-16 19:46 +1000
                    What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 21:16 -0700
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 14:35 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 22:37 -0700
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 15:48 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 09:21 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-18 09:32 -0400
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Ben Finney <ben+python@benfinney.id.au> - 2016-07-18 14:46 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 22:22 -0700
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-18 19:29 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 13:00 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 20:15 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 03:24 -0700
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 20:37 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 14:38 +0300
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Peter Otten <__peter__@web.de> - 2016-07-18 14:58 +0200
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:42 +1000
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 21:58 -0700
                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-19 15:30 +1000
                                Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-20 15:42 +1000
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-20 16:11 +1000
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-20 09:09 +0200
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 10:25 +0300
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve@pearwood.info> - 2016-07-20 22:47 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 16:54 +0300
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 00:26 +1000
                                          Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 17:59 +0300
                                            Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:38 -0700
                                              Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-21 10:52 +0300
                                                Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 18:46 +1000
                                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-21 12:09 +0300
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-22 00:54 +0100
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Kaynor <ckaynor@zindagigames.com> - 2016-07-21 17:43 -0700
                                          Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-22 17:14 +0100
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:28 -0700
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 15:35 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:52 -0700
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-21 16:34 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-21 06:14 -0700
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve@pearwood.info> - 2016-07-22 02:10 +1000
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-19 15:27 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 03:14 -0700
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-18 09:25 -0600
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 18:40 +0300
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 18:55 +0300
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-18 11:13 -0600
                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 21:58 +0300
                                  Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 17:36 -0700
                                    Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:16 +1000
                                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 20:26 -0700
                                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 01:22 -0400
                                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-19 10:46 -0700
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 16:35 -0400
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 01:17 +0300
                                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-19 23:15 -0400
                                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 10:16 +0300
                                                  Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-20 10:00 -0400
                                                    Re: What exactly is "exact" (was Clean Singleton Docstrings) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-21 10:46 +1200
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-19 16:27 -0600
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 02:09 +0300
                                              Re: What exactly is "exact" (was Clean Singleton Docstrings) alister <alister.ware@ntlworld.com> - 2016-07-20 13:24 +0000
                                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-21 14:04 +1000
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-19 17:01 -0700
                                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-20 11:07 +1200
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 02:20 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:03 +1000
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-18 09:25 -0400
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:21 +1000
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Ben Finney <ben+python@benfinney.id.au> - 2016-07-19 10:21 +1000
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-16 17:27 +1000
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-16 10:58 +0300
                Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-16 14:04 -0400
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-16 21:43 +0300
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 07:02 +1000
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-17 00:27 +0300
                    Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 08:18 +1000
                      Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-17 10:41 +0300
                        Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 17:51 +1000
                        Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-17 04:03 -0400
                          Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-17 20:35 +1000
                        Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-17 04:08 -0400
                        Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 18:44 +1000
        Re: Clean Singleton Docstrings Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-13 18:25 -0600
    Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-08 09:44 +0200
      Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-08 01:53 -0700
    Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 23:16 -0400

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

#111670 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Wed, 20 Jul 2016 05:09 pm, Antoon Pardon wrote:

> Op 20-07-16 om 07:42 schreef Steven D'Aprano:
>> Floating point maths is hard, thinking carefully about what you are doing
>> and whether it is appropriate to use == or a fuzzy almost-equal
>> comparison, or if equality is the right way at all.
>>
>> "But thinking is hard, can't you just tell me the answer?"
>>
>> No. But I can give some guidelines:
>>
>> Floating point arithmetic is deterministic, it doesn't just randomly mix
>> in error out of spite or malice. So in principle, you can always estimate
>> the rounding error from any calculation -- and sometimes there is none.
> 
> I would like to see a practical example of such an outcome.


[steve@ando ~]$ cd /home/steve/python/python-dev/3.4/Lib/test/
[steve@ando test]$ grep self.assertEqual test_statistics.py | wc -l
95


Not all of the 95 examples of using assertEqual apply to float values, but a
good proportion of them do. And if I were a better computer scientist,
there would probably be a lot more assertEquals in my code. A lot of the
time that I do a fuzzy comparison its because I'm too lazy or not good
enough to get a better result.

I am not a good computer scientist. But Bruce Dawson *is* a good computer
scientist:

https://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-floatsso-test-them-all/

Quote:

    Conventional wisdom says that you should never compare two floats
    for equality – you should always use an epsilon. Conventional
    wisdom is wrong.

    I’ve written in great detail about how to compare floating-point
    values using an epsilon, but there are times when it is just not
    appropriate. Sometimes there really is an answer that is correct,
    and in those cases anything less than perfection is just sloppy.

    So yes, I’m proudly comparing floats to see if they are equal.



>> Arithmetic on integer-values (e.g. 1.0) is always exact, up to a limit of
>> either 2**53 or approximately 1e53, I forget which. (That's why most
>> Javascript programmers fail to notice that they don't have an integer
>> type.) So long as you're using operations that only produce integer
>> values from integer arguments (such as + - * // but not / ) then all
>> calculations are exact. It is a waste of time to do:
>>
>> x = 2.0
>> y = x*1002.0
>> is_equal(y, 2004.0, 1e-16)
>>
>> when you can just do y == 2004.0.
> 
> But why perforem integer arithmetics in floats, isn't that a waste of time
> too? I really see no reason to use floats if you know all your results
> will be integers.

In Python, it's probably neither harmful nor useful. The cost of dealing
with boxed values (objects rather than low-level machine values) will
probably outweigh any performance gain one way or the other.

But in lower-level languages, you might find that floating point arithmetic
is faster than integer arithmetic, if you can pass the work on to a FPU
instead of a (slow?) CPU. Or not. It depends on the machine.

Or you might be using a language like Javascript, which intentionally has
only floats for numbers. That's okay, you can still perform exact integer
arithmetic, so long as you stay within the bounds of ±2**16.

Not even in Javascript do you need to write something like this:

x = 0.0
for i in range(20):
    x += 1.0

assert abs(x - 20.0) <= 1e-16




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

#111672 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

Steven D'Aprano <steve@pearwood.info>:

> I am not a good computer scientist. But Bruce Dawson *is* a good
> computer scientist:
>
> https://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-f
> loatsso-test-them-all/
>
> Quote:
>
>     Conventional wisdom says that you should never compare two floats
>     for equality – you should always use an epsilon. Conventional
>     wisdom is wrong.
>
>     I’ve written in great detail about how to compare floating-point
>     values using an epsilon, but there are times when it is just not
>     appropriate. Sometimes there really is an answer that is correct,
>     and in those cases anything less than perfection is just sloppy.
>
>     So yes, I’m proudly comparing floats to see if they are equal.

The point of view in the linked article is very different from that of
most application programming that makes use of floating-point numbers.

Yes, if what you are testing or developing is a numeric or mathematical
package, you should test its numeric/mathematical soundness to the bit.
However, in virtually any other context, you have barely any use for
a floating-point equality comparison because:

 1. Floating-point numbers are an approximation of *real numbers*. Two
    independently measured real numbers are never equal because under
    any continuous probability distribution, the probability of any
    given real number is zero. Only continuous ranges can have nonzero
    probabilities.

 2. Floating-point numbers are *imperfect approximations* of real
    numbers. Even when real numbers are derived exactly, floating-point
    operations may introduce "lossy compression artifacts" that have to
    be compensated for in application programs.

What you have to do exactly to compensate for these challenges depends
on the application, and is very easy to get wrong. However, if an
application programmer is using == to compare two floating-point data
values, it is almost certainly a mistake.

> Or you might be using a language like Javascript, which intentionally
> has only floats for numbers. That's okay, you can still perform exact
> integer arithmetic, so long as you stay within the bounds of ±2**16.
>
> Not even in Javascript do you need to write something like this:
>
> x = 0.0
> for i in range(20):
>     x += 1.0
>
> assert abs(x - 20.0) <= 1e-16

Correct because Javascript makes an exactness guarantee of its integers
(I imagine).

In Python, I think it would usually be bad style to rely even on:

   1.0 + 1.0 == 2.0

It is very difficult to find a justification for that assumption in
Python's specifications. What we have:

   Floating-point numbers are represented in computer hardware as base 2
   (binary) fractions.
   <URL: https://docs.python.org/3/tutorial/floatingpoint.html>

   almost all platforms map Python floats to IEEE-754 “double precision”
   <URL: https://docs.python.org/3/tutorial/floatingpoint.html#represent
   ation-error>

   numbers.Real (float)
     These represent machine-level double precision floating point
     numbers. You are at the mercy of the underlying machine
     architecture (and C or Java implementation) for the accepted range
     and handling of overflow.
   <URL: https://docs.python.org/3/reference/datamodel.html#the-standar
   d-type-hierarchy>


I believe a Python implementation that would have:

   1.0 + 1.0 != 2.0

would not be in violation of Python's data model. In fact, even:

   1.0 != 1.0

might be totally conformant. For example, we could have a new underlying
real-number technology that stored the value in an *analogous* format
(say, an ultra-precise voltage level) and performed the calculations
using some fast, analogous circuitry.


Marko

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

#111674 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Wed, Jul 20, 2016 at 11:54 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>  2. Floating-point numbers are *imperfect approximations* of real
>     numbers. Even when real numbers are derived exactly, floating-point
>     operations may introduce "lossy compression artifacts" that have to
>     be compensated for in application programs.

This is the kind of black FUD that has to be fought off. What
"compression artifacts" are introduced? The *only* lossiness in IEEE
binary floating-point arithmetic is rounding. (This is the bit where
someone like Steven is going to point out that there's something else
as well.) Unless you are working with numbers that require more
precision than you have available, the result should be perfectly
accurate. And there are other systems far less 'simple'. Can you
imagine this second assertion failing?

assert x <= y # if not, swap the values
assert x <= (x+y)/2 <= y

Because it can with decimal.Decimal, due to the way rounding happens in decimal.

ChrisA

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

#111675 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

Chris Angelico <rosuav@gmail.com>:

> On Wed, Jul 20, 2016 at 11:54 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>  2. Floating-point numbers are *imperfect approximations* of real
>>     numbers. Even when real numbers are derived exactly,
>>     floating-point operations may introduce "lossy compression
>>     artifacts" that have to be compensated for in application
>>     programs.
>
> This is the kind of black FUD that has to be fought off. What
> "compression artifacts" are introduced? The *only* lossiness in IEEE
> binary floating-point arithmetic is rounding.

You are joining me in spreading the FUD. Yes, the immediate lossiness is
rounding, but the effects of that rounding can result in atrocious
accumulative errors in numeric calculations.

> Unless you are working with numbers that require more precision than
> you have available, the result should be perfectly accurate.

Whoa, hold it there! Catastrophic cancellation (<URL:
https://en.wikipedia.org/wiki/Loss_of_significance>) is not a myth:

   >>> 0.2 / (0.2 - 0.1)
   2.0
   >>> 0.2 / ((2e15 + 0.2) - (2e15 + 0.1))
   0.8

You can fall victim to the phenomenon when you collect statistics over a
long time. The cumulative sum of a measurement can grow very large,
which causes the naïve per-second rate calculation to become
increasingly bogus.


Marko

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

#111693 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Wednesday, July 20, 2016 at 8:29:25 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :
> 
> > On Wed, Jul 20, 2016 at 11:54 PM, Marko Rauhamaa  wrote:
> >>  2. Floating-point numbers are *imperfect approximations* of real
> >>     numbers. Even when real numbers are derived exactly,
> >>     floating-point operations may introduce "lossy compression
> >>     artifacts" that have to be compensated for in application
> >>     programs.
> >
> > This is the kind of black FUD that has to be fought off. What
> > "compression artifacts" are introduced? The *only* lossiness in IEEE
> > binary floating-point arithmetic is rounding.
> 
> You are joining me in spreading the FUD. Yes, the immediate lossiness is
> rounding, but the effects of that rounding can result in atrocious
> accumulative errors in numeric calculations.
> 
> > Unless you are working with numbers that require more precision than
> > you have available, the result should be perfectly accurate.
> 
> Whoa, hold it there! Catastrophic cancellation (<URL:
> https://en.wikipedia.org/wiki/Loss_of_significance>) is not a myth:

Whose lead para starts:


| Catastrophic cancellation… The effect is that the number of accurate 
| (significant) digits in the result is reduced unacceptably. Ways to avoid this 
| effect are studied in numerical analysis.

I would go a step further:
The field of numerical analysis came into existence only because this fact
multiplied by the fact that computers do their (inaccurate ≠ inexact) computations
billions of times faster than we do
makes significance a very significant problem!

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

#111704 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

Rustom Mody <rustompmody@gmail.com>:
> The field of numerical analysis came into existence only because this
> fact multiplied by the fact that computers do their (inaccurate ≠
> inexact) computations billions of times faster than we do makes
> significance a very significant problem!

A couple of related anecdotes involving integer errors.

1. I worked on a (video) product that had to execute a piece of code
   every 7 µs or so. A key requirement was that the beat must not drift
   far apart from the ideal over time. At first I thought the
   traditional nanosecond resolution would be sufficient for the purpose
   but then made a calculation:

        maximum rounding error = 0.5 ns/7 µs
                               = 70 µs/s
                               = 6 s/day

   That's why I decided to calculate the interval down to a femtosecond,
   whose error was well within our tolerance.

2. After running the LXDE GUI on my 32-bit Linux environment for some
   time, the CPU utilization monitor showed the CPU was mysteriously
   doing work 100% of the time. The only way out was to reboot the
   machine.

   After a few months and a few reboots, I investigated the situation
   more carefully. It turned out LXDE's CPU meter was reading jiffy
   counts from a textual /proc file with scanf("%ld"). Jiffies start
   from 0 at the time of the boot and increment every millisecond. Thus,
   the maximum signed 32-bit integer is reached in less than 25 days.

   When scanf("%ld") overflows, it sets the value to MAX_LONG. That
   effectively meant time stopped going forward and all rate
   calculations would shoot through the roof. This problem would not
   have occurred if the C standard consistently specified modulo
   arithmetics for integer operations.

   The solution was to use scanf("%lld") instead.


Marko

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

#111705 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Thu, Jul 21, 2016 at 5:52 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> A couple of related anecdotes involving integer errors.
>
> 1. I worked on a (video) product that had to execute a piece of code
>    every 7 µs or so. A key requirement was that the beat must not drift
>    far apart from the ideal over time. At first I thought the
>    traditional nanosecond resolution would be sufficient for the purpose
>    but then made a calculation:
>
>         maximum rounding error = 0.5 ns/7 µs
>                                = 70 µs/s
>                                = 6 s/day
>
>    That's why I decided to calculate the interval down to a femtosecond,
>    whose error was well within our tolerance.

I'd be curious to know whether, had you used nanosecond resolution,
you ever would have seen anything like that +/- 6s/day error. One
convenient attribute of the real world [1] is that, unless there's a
good reason for it to do otherwise [2], random error will tend to
cancel out rather than accumulate. With error of +/- 0.5 ns, assume
(for the sake of argument) that the actual error at each measurement
is random.choice((-0.4, -0.3, -0.2, -0.1, 0.1, 0.2, 0.3, 0.4)) ns,
with zero and the extremes omitted to make the calculations simpler.
In roughly twelve billion randomizations (86400 seconds divided by
7µs), the chances of having more than one billion more positive than
negative are... uhh.... actually, I don't know how to calculate
probabilities off numbers that big, but pretty tiny. So you're going
to have at least 5.5 billion negatives to offset your positives (or
positives to offset your negatives, same diff); more likely they'll be
even closer. So if you have (say) 5.5 to 6.5 ratio of signs, what
you're actually working with is half a second per day of accumulated
error - and I think you'd have a pretty tiny probability of even
*that* extreme a result. If it's more like 5.9 to 6.1, you'd have 0.1
seconds per day of error, at most. Plus, the same probabilistic
calculation can be done for days across a month, so even though the
theory would let you drift by three minutes a month, the chances of
shifting by even an entire second over that time are fairly slim.

This is something where I'd be more worried about systematic bias in
the code than anything from measurement or rounding error.

(I don't believe I've ever actually used a computer that's capable of
nanosecond-accurate time calculations. Generally they return time in
nanoseconds for consistency, but they won't return successive integer
values. You must have been on some seriously high-end hardware -
although that doesn't surprise me much, given that you were working on
a video product.)

ChrisA

[1] Believe you me, it has no shortage of INconvenient attributes, so
it's nice to have one swing the balance back a bit!
[2] If there's systematic error - if your 7 µs is actually averaging
7.25 µs - you need to deal with that separately.

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

#111706 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

Chris Angelico <rosuav@gmail.com>:

> On Thu, Jul 21, 2016 at 5:52 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> A couple of related anecdotes involving integer errors.
>>
>> 1. I worked on a (video) product that had to execute a piece of code
>>    every 7 µs or so. A key requirement was that the beat must not drift
>>    far apart from the ideal over time. At first I thought the
>>    traditional nanosecond resolution would be sufficient for the purpose
>>    but then made a calculation:
>>
>>         maximum rounding error = 0.5 ns/7 µs
>>                                = 70 µs/s
>>                                = 6 s/day
>>
>>    That's why I decided to calculate the interval down to a femtosecond,
>>    whose error was well within our tolerance.
>
> I'd be curious to know whether, had you used nanosecond resolution,
> you ever would have seen anything like that +/- 6s/day error. One
> convenient attribute of the real world [1] is that, unless there's a
> good reason for it to do otherwise [2], random error will tend to
> cancel out rather than accumulate. With error of +/- 0.5 ns, assume
> (for the sake of argument) that the actual error at each measurement
> is random.choice((-0.4, -0.3, -0.2, -0.1, 0.1, 0.2, 0.3, 0.4)) ns,

No, this is a systematic error due to the rounding of a rational number
to the nearest nanosecond interval. Systematic errors of this kind are a
real thing and not even all that uncommon.

> (I don't believe I've ever actually used a computer that's capable of
> nanosecond-accurate time calculations. Generally they return time in
> nanoseconds for consistency, but they won't return successive integer
> values. You must have been on some seriously high-end hardware -
> although that doesn't surprise me much, given that you were working on
> a video product.)

Nanosecond, even femtosecond, calculations are trivially simple integer
arithmetics that can be performed with pencil and paper. The hardware
was nothing fancy, and the timing error due to various hardware,
software and network realities was in the order of ±100 µs. That was
tolerable and could be handled through buffering. However, a cumulative
error of 6 seconds per day was *not* tolerable.

The calculations needed to be extremely simple because the interrupt
routine had to execute every 7 microseconds. You had to let the hardware
RTC do most of the work and do just a couple of integer operations in
the interrupt routine. In particular, you didn't have time to
recalculate and reprogram the RTC at every interrupt.


Marko

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

#111729 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

Steven D'Aprano <steve@pearwood.info> writes:
<snip>
> Or you might be using a language like Javascript, which intentionally has
> only floats for numbers. That's okay, you can still perform exact integer
> arithmetic, so long as you stay within the bounds of ±2**16.

Small point: it's 2**52.

<snip>
-- 
Ben.

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

#111730 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Thu, Jul 21, 2016 at 4:54 PM, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
> <snip>
> > Or you might be using a language like Javascript, which intentionally has
> > only floats for numbers. That's okay, you can still perform exact integer
> > arithmetic, so long as you stay within the bounds of ±2**16.
>
> Small point: it's 2**52.
>

If you really want to be picky, it is 2**53, inclusive:

>>> 2**53-2.0

9007199254740990.0

>>> 2**53-1.0

9007199254740991.0

>>> 2**53+0.0 # Can no longer store odd numbers, but 2**53 is even so it
can still be stored.

9007199254740992.0

>>> 2**53+1.0

9007199254740992.0

>>> 2**53+2.0
9007199254740994.0

This works as there is an implied one bit in the field for floats, giving
53 bits of storage despite only having 52 bits of storage. As the sign is
stored in a separate bit, the same limit applies to both positive and
negative numbers.

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

#111765 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

Chris Kaynor <ckaynor@zindagigames.com> writes:

> On Thu, Jul 21, 2016 at 4:54 PM, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Steven D'Aprano <steve@pearwood.info> writes:
>> <snip>
>> > Or you might be using a language like Javascript, which intentionally has
>> > only floats for numbers. That's okay, you can still perform exact integer
>> > arithmetic, so long as you stay within the bounds of ±2**16.
>>
>> Small point: it's 2**52.
>>
>
> If you really want to be picky, it is 2**53, inclusive:

Yes, I mis-typed.  Typical, I suppose, for a correction!

To add something useful, there are properties Number.MAX_SAFE_INTEGER
and Number.MIN_SAFE_INTEGER which are 2**53 - 1 and -2**53 + 1.  These
are the largest (and smallest) integers such that i and i+1 (or i and
i-1) are exactly representable.

<snip>
-- 
Ben.

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

#111691 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Wednesday, July 20, 2016 at 11:13:05 AM UTC+5:30, Steven D'Aprano wrote:
> On Tuesday 19 July 2016 14:58, Rustom Mody wrote:
> 
> > So I again ask: You say «"Never compare floats for equality" is a pernicious
> > myth»
> 
> It is the word *never* which makes it superstition. If people said "Take care 
> with using == for floats, its often not what you want" I would have no argument 
> with the statement.
> 
> I'd even (reluctantly) accept "usually not what you want". But "never" is out-
> and-out cargo-cult programming.

You seem to not understand the realities of teaching.
You (teacher in general) cannot say a saga; only epigrams
You cannot transmit wisdom (even if you own some) just a bit of savviness/cleverness.

So let me ask the question again differently:
How many errors happen by people not using ε-neighborhood checks instead of == checks
How many errors happen by the opposite (mis)use?

IOW “myth”... ok “pernicious myth” Not

BTW APL whose main domain of application is scientific chooses to enshrine
this —equality is ε-neighborhood checking not exact equality checking — into its builtin ‘==’

And http://www.dyalog.com/uploads/documents/Papers/tolerant_comparison/tolerant_comparison.htm

ε is spelt ⎕ct (Comparison Tolerance)
And of course == is spelt =

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

#111692 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Thu, Jul 21, 2016 at 3:28 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> ε is spelt ⎕ct (Comparison Tolerance)
> And of course == is spelt =

spelt is spelled spelled. Unless, of course, you mean the wheat variety.

ChrisA

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

#111694 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Thursday, July 21, 2016 at 11:05:28 AM UTC+5:30, Chris Angelico wrote:
> On Thu, Jul 21, 2016 at 3:28 PM, Rustom Mody  wrote:
> > ε is spelt ⎕ct (Comparison Tolerance)
> > And of course == is spelt =
> 
> spelt is spelled spelled. Unless, of course, you mean the wheat variety.

Love it!
Though not everyone agrees (including Australians!)
http://english.stackexchange.com/questions/5712/spelt-vs-spelled

Anyway... Ive been collecting quines/self-referential statements for classes
on Theory of computation.

Like these from Douglas Hofstadter.
To which I’ll add yours

You cant have “your cake” and spell it “too”

You cant have your use and mention it too

If this sentence were in Chinese it would say something else

.siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI

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

#111698 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Thursday 21 July 2016 15:28, Rustom Mody wrote:

> On Wednesday, July 20, 2016 at 11:13:05 AM UTC+5:30, Steven D'Aprano wrote:
>> On Tuesday 19 July 2016 14:58, Rustom Mody wrote:
>> 
>> > So I again ask: You say «"Never compare floats for equality" is a
>> > pernicious myth»
>> 
>> It is the word *never* which makes it superstition. If people said "Take
>> care with using == for floats, its often not what you want" I would have no
>> argument with the statement.
>> 
>> I'd even (reluctantly) accept "usually not what you want". But "never" is
>> out- and-out cargo-cult programming.
> 
> You seem to not understand the realities of teaching.
> You (teacher in general) cannot say a saga; only epigrams

Is "Don't use exact equality unless you know what you're doing" enough of an 
epigram for you?


> You cannot transmit wisdom (even if you own some) just a bit of
> savviness/cleverness.

Maybe so, but that's no excuse for transmitting outright misinformation and 
superstition. In physics, dealing with motion in the presence of energy losses 
is hard, and beginning and intermediate levels of physics will generally 
explicitly or implicitly ignore friction and air resistance. But physics 
teachers do not teach that "air resistance doesn't exist; you mustn't try to 
take friction into account". They teach that it is a simplification.




> So let me ask the question again differently:
> How many errors happen by people not using ε-neighborhood checks instead of
> == checks How many errors happen by the opposite (mis)use?

Precisely 35, and 17812, respectively.


> IOW “myth”... ok “pernicious myth” Not
> 
> BTW APL whose main domain of application is scientific chooses to enshrine
> this —equality is ε-neighborhood checking not exact equality checking — into
> its builtin ‘==’

I have a lot of respect for Ken Iverson, and a lot of admiration for language 
designers willing to experiment with alternate paradigms.

But keeping in mind that in APL, if you set ⎕ct to 0 you get an exact 
comparison, can you find any quotes from Iverson saying that you should *never* 
perform exact equality comparisons?



> And
> 
http://www.dyalog.com/uploads/documents/Papers/tolerant_comparison/tolerant_comparison.htm

Nice resource, thank you.


> ε is spelt ⎕ct (Comparison Tolerance)
> And of course == is spelt =




-- 
Steve

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

#111707 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Thursday, July 21, 2016 at 12:04:35 PM UTC+5:30, Steven D'Aprano wrote:
> On Thursday 21 July 2016 15:28, Rustom Mody wrote:
> > BTW APL whose main domain of application is scientific chooses to enshrine
> > this —equality is ε-neighborhood checking not exact equality checking — into
> > its builtin ‘==’
> 
> I have a lot of respect for Ken Iverson, and a lot of admiration for language 
> designers willing to experiment with alternate paradigms.

This choice has significant(!!) costs: Fuzzy equality is not transitive:
One can get
a = b ∧ b = c ∧ a ≠ c
> 
> But keeping in mind that in APL, if you set ⎕ct to 0 you get an exact 
> comparison, can you find any quotes from Iverson saying that you should *never* 
> perform exact equality comparisons?

There you go with your strawmen!
Remember it was you (and Chris) who expressed extreme positions:
“Pernicious myth” “FUD” etc

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

#111720 — Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)]

On Thu, 21 Jul 2016 11:14 pm, Rustom Mody wrote:

> On Thursday, July 21, 2016 at 12:04:35 PM UTC+5:30, Steven D'Aprano wrote:
>> On Thursday 21 July 2016 15:28, Rustom Mody wrote:
>> > BTW APL whose main domain of application is scientific chooses to
>> > enshrine this —equality is ε-neighborhood checking not exact equality
>> > checking — into its builtin ‘==’
>> 
>> I have a lot of respect for Ken Iverson, and a lot of admiration for
>> language designers willing to experiment with alternate paradigms.
> 
> This choice has significant(!!) costs: Fuzzy equality is not transitive:
> One can get
> a = b ∧ b = c ∧ a ≠ c
>> 
>> But keeping in mind that in APL, if you set ⎕ct to 0 you get an exact
>> comparison, can you find any quotes from Iverson saying that you should
>> *never* perform exact equality comparisons?
> 
> There you go with your strawmen!
> Remember it was you (and Chris) who expressed extreme positions:
> “Pernicious myth” “FUD” etc


And YOU'RE the one who is raising APL as an argument *against* my
characterisation.

Do you think that Iverson would agree with the conventional wisdom that we
should NEVER test floats for exact equality?

Do you know of ANY expert in numeric computation who will agree with the
conventional wisdom? If so, who?

I'll admit that I've stolen my description of this rule as "superstition"
from perhaps the world's foremost authority on numeric computation,
Professor William Kahan. (See the forward to "Apple Numerics Manual, Second
Edition, 1988.) You don't like my use of the term "pernicious"? In my
opinion, any conventional wisdom which keeps people *more* rather than
*less* ignorant is pernicious. Anything which discourages them from testing
their numeric functions to the full precision possible is pernicious.
Anything which encourages the idea that numeric computation using floats is
non-deterministic is pernicious.

But if you don't agree, feel free to dismiss the word as mere hyperbola and
MOVE ON. You don't have to nit pick about every word I use.

The bottom line is, while it is often true that using exact equality is
going to surprise people, the conventional wisdom to NEVER do so is both
(1) factually wrong, there are plenty of examples where one can and should
use exact equality, and (2) rather useless, as the conventional wisdom
gives no clue as to the practicalities of what to replace it with.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

#111628 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Tue, Jul 19, 2016 at 1:42 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> And then you get these sorts of functions:
>>
>> EPSILON = 0.000001 # Adjust to control numeric accuracy
>> def is_equal(f1, f2, epsilon=EPSILON):
>>     if abs(f1) > abs(f2):
>>         f1, f2 = f2, f1
>>     return abs(f2-f1) < f1*epsilon
>>
>> and interminable debates about how to pick an epsilon, whether it
>> should be relative to the smaller value (as here) or the larger (use
>> f2 instead), or maybe should be an absolute value, or maybe it should
>> be relative to the largest/smallest value that was ever involved in
>> the calculation, or........
>
> Your code is buggy. Consider:
>
> py> is_equal(-1.0, -1.0)
> False

Duh, I got the < and <= bug! Shows how easy it is to get this kind of
function wrong. (Even more so, it shows how easy it is to get code
wrong when you type straight into an email and never test it.)

> Earlier you mentioned "interminable debates
> about how to pick an epsilon", but the reason for that is that it is
> really, really hard to pick an epsilon in any systematic, objective way.

Yeah, and that's the problem. If you're working with some concept of
measurement error, what you actually mean is that every number in your
calculation is actually a range centered on that number; which means
that "equality" really means "overlapping ranges". Epsilon-based
equality is just that, only with a global epsilon instead of one that
actually cares about the real error value. How can that NOT be doomed
to failure?

ChrisA

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

#111599 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Monday, July 18, 2016 at 2:59:56 PM UTC+5:30, Steven D'Aprano wrote:
> On Monday 18 July 2016 14:16, Rustom Mody wrote:

> > AIUI…
> > There are two almost completely unrelated notions of exact
> > 
> > 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are
> > approximations.
> >    We could call these inexact forms of ⅓
> 
> But 0.3 is an exact representation of 3/10, 0.1 + 0.2, 0.6/2, etc.
> 
> 
> > 2. Measurement and observation produces numbers.  These are inexact
> > inherently.
> > 
> > Scheme's notion of exact is towards capturing the second notion.
> 
> I don't see anything in the Guile documentation you linked to which supports 
> that interpretation.

Exact example :: index operations into data structures may need to know the index exactly, as may some operations on polynomial coefficients in a symbolic algebra system.
Inexact example :: the results of measurements are inherently inexact, and irrational numbers may be approximated by rational and therefore inexact approximations.

[from the Scheme standard http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-6.html ]

I believe the two clauses:
- measurements inherently inexact
- rational approximations to irrationals

The first represents the basic intention
The second represents the fact that pragmatically we are stuck with things like
floating point as the same chapter indicates at start:


|| This chapter describes Scheme's model for numbers. It is important to
|| distinguish between the mathematical numbers, the Scheme objects that
|| attempt to model them, the machine representations used to implement
|| the numbers, and notations used to write numbers. In this report, the
|| term number refers to a mathematical number, and the term number
|| object refers to a Scheme object representing a number. This report
|| uses the types complex, real, rational, and integer to refer to both
|| mathematical numbers and number objects. The fixnum and flonum types
|| refer to special subsets of the number objects, as determined by
|| common machine representations, as explained below.
||  
||  Numbers may be arranged into a tower of subsets in which each level is a subset of the level above it:
||  
|| number
||     complex
||     real
||     rational
||     integer
||  
|| For example, 5 is an integer. Therefore 5 is also a rational, a real,
|| and a complex. The same is true of the number objects that model 5.
||  
|| There is no simple relationship between the subset that contains a
|| number and its representation inside a computer. For example, the
|| integer 5 may have several represen || operations treat number objects as abstract data, as independent of
|| their representation as possible. Although an implementation of Scheme
|| may use many different representations for numbers, this should not be
|| apparent to a casual programmer writing simple programs.

Whether scheme achieves all these laudable and lofty goals of
representation independence, genuine mathematical subsetting (unlike
the usual programming story where float and int are disjoint) etc,
I will along with Marko say: “Cant say if it has turned out practicable”

Practicability has of course many variables
floating point h/w induces floating point languages perpetuates the h/w
perpetuates the languages… etc

Are viable alternatives possible?? Dunno…

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

#111609 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Mon, Jul 18, 2016 at 3:29 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Monday 18 July 2016 14:16, Rustom Mody wrote:
>> In short one could think of inexact and exact — in scheme's intended
>> semantics — as better called scientific (or science-ic) and mathematic
>> numbers.
>
> I don't think so. "Science" uses both experimentally-derived numbers (e.g. G,
> c, the mass of the electron) and numbers known exactly (√2, e, π).

Off-topic, c being a fundamental constant is actually in the latter
category. Its *exact* value is 299792458 m/s.

The length of the meter, on the other hand, is defined as the distance
traveled by light in a vacuum in 1/299792458 seconds and is subject to
the precision of measurements.

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

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

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

csiph-web