Float

[Cai Gengyang]

Can someone explain in layman's terms what "float" means ?

>>> x = float(input("Write a number"))
Write a number 16

[Lutz Horn]

Am 07/29/2016 um 11:44 AM schrieb Cai Gengyang:
> Can someone explain in layman's terms what "float" means ?

The Python builtin float[1]

> Return a floating point number constructed from a number or string x.

A floating point number[2] is number that is not an integer (and not a
complex number). It

> is the formulaic representation that approximates a real number

since computers can't handle handle "real" real numbers which would
require infinite precision.

Examples are

1.0
3.14159

Lutz

[1] https://docs.python.org/3/library/functions.html#float
[2] https://en.wikipedia.org/wiki/Floating_point

--
https://www.lhorn.de/
https://emailselfdefense.fsf.org/de/

[Ben Finney]

Cai Gengyang <gengy...@gmail.com> writes:

> Can someone explain in layman's terms what "float" means ?

They are a compromise: in a known number of bits and with explict
very-fast hardware support, represent numbers at a large range of
scales. The compromise is that the values have limited precision for
representing those numbers.

<URL:https://en.wikipedia.org/wiki/Floating_point>

If you want exact representations of numbers, you don't want
floating-point numbers; you want Fraction or Decimal or integer etc.

If you just want to have fairly-good precision of fractional numbers, as
fast as your computer can compute them, then maybe the built-in
floating-point numbers are what you want.

There is no substitute for knowing the characteristics of floating-point
numbers, and using that information to decide when they are appropriate
and when they are not.

--
\ “Books and opinions, no matter from whom they came, if they are |
`\ in opposition to human rights, are nothing but dead letters.” |
_o__) —Ernestine Rose |
Ben Finney

[Steven D'Aprano]

On Fri, 29 Jul 2016 07:44 pm, Cai Gengyang wrote:

> Can someone explain in layman's terms what "float" means ?

Floating point number:

https://en.wikipedia.org/wiki/Floating_point

As opposed to fixed point numbers:

https://en.wikipedia.org/wiki/Fixed-point_arithmetic

Python floats use 64 bits (approximately 18 decimal digits). Because the
decimal point can "float" from place to place, they can represent very
small numbers:

1.2345678901234567e-100

and very big numbers:

1.2345678901234567e100

using just 64 bits. If it were *fixed* decimal place, the range would be a
lot smaller: for example, suppose the decimal place was fixed after three
digits. The largest number would be 999.999999999999999 and the smallest
would be 0.000000000000001.




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

[Cai Gengyang]

Cool ... can you give a concrete example ?

[Steven D'Aprano]

On Sat, 30 Jul 2016 08:21 pm, Cai Gengyang wrote:

> Cool ... can you give a concrete example ?

A concrete example of a float?

I already gave two:

>> Python floats use 64 bits (approximately 18 decimal digits). Because the
>> decimal point can "float" from place to place, they can represent very
>> small numbers:
>>
>> 1.2345678901234567e-100
>>
>> and very big numbers:
>>
>> 1.2345678901234567e100

Here are some more:

0.5 # one half
0.25 # one quarter
7.5 # seven and a quarter
0.001 # one thousandth

12345.6789
# twelve thousand, three hundred and forty-five, point six seven eight nine

-1.75 # minus one point seven five
0.0 # zero
3.0 # three

1.23e45 # one point two three times ten to the power of forty-five

[Cai Gengyang]

You mentioned that : A floating point number[2] is number that is not an integer (and not a
complex number)

Hence ,

10 is not a floating point number because it is an integer
25 is not a floating point number because it is an integer
7 + 3i is not a floating number because it is a complex number
8 + 5i is not a floating number because it is a complex number.

Is 3.0 a floating number ? It is a rational number, not an integer right ?

[Chris Angelico]

On Sat, Jul 30, 2016 at 9:44 PM, Cai Gengyang <gengy...@gmail.com> wrote:
> You mentioned that : A floating point number[2] is number that is not an integer (and not a
> complex number)
>
> Hence ,
>
> 10 is not a floating point number because it is an integer
> 25 is not a floating point number because it is an integer
> 7 + 3i is not a floating number because it is a complex number
> 8 + 5i is not a floating number because it is a complex number.
>
> Is 3.0 a floating number ? It is a rational number, not an integer right ?

In a computing context, data types are incredibly significant. So yes,
3.0 *is* a floating-point number. It's equal to the integer 3, because
they represent the same number, but it's not identical to it. You can
convert from one to the other with the built-ins int and float:

>>> 3.0 == 3
True
>>> int(3.0)
3
>>> float(3)
3.0

ChrisA

[eryk sun]

On Sat, Jul 30, 2016 at 4:03 PM, Dennis Lee Bieber
<wlf...@ix.netcom.com> wrote:
> And in a rather convoluted route, one can get to the underlying
> representation...
>
>>>> import struct
>>>> f = struct.pack(">f", 3.0)
>>>> i = struct.pack(">i", 3)
>>>> fi = struct.unpack(">i", f)
>>>> ii = struct.unpack(">i", i) #really a waste of time
>>>> "0x%8.8X 0x%8.8X" % (fi[0], ii[0])
> '0x40400000 0x00000003'

A CPython float is a C double-precision float ('d'), which is an IEEE
754 binary64 on all of CPython's supported platforms. This format has
a precision of 15 decimal digits (rounded down from 15.95). Uniquely
representing a C double requires 17 decimal digits. See the following
Wikipedia article for more information:

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

The underlying representation of 3.0 is as follows:

>>> n = 3.0
>>> hex(struct.unpack('Q', struct.pack('d', n))[0])
'0x4008000000000000'

You can confirm this by attaching a native debugger (such as gdb on
Linux or cdb on Windows) and pointer casting the float object's
ob_fval field as a uint64_t integer:

Linux (python3-dbg):

>>> id(n)
140737353618480
(gdb) p/x *(uint64_t *)&((PyFloatObject *)140737353618480)->ob_fval
$1 = 0x4008000000000000

Windows (python_d.exe):

>>> id(n)
2398135104848
0:000> ?? *(ULONG64 *)&((PyFloatObject *)2398135104848)->ob_fval
unsigned int64 0x40080000`00000000

We can break this down as follows:

sign = 0x400 >> 11
= 0
exponent = (0x400 & (1 << 11 - 1)) - 1023
= 1
significand = 1 + 0x8000000000000 / 2 ** 52
= 1.5
n = (-1) ** sign * significand * 2 ** exponent
= 3.0

Python's float type has a hex() method that represents the value in
hexadecimal as follows:

>>> n.hex()
'0x1.8000000000000p+1'

This format shows the implicit integer bit of the normalized
significand and decodes the sign and exponent values for you.

[Rustom Mody]

On Saturday, July 30, 2016 at 5:21:44 PM UTC+5:30, Chris Angelico wrote:

> On Sat, Jul 30, 2016 at 9:44 PM, Cai Gengyang wrote:
> > You mentioned that : A floating point number[2] is number that is not an integer (and not a
> > complex number)
> >
> > Hence ,
> >
> > 10 is not a floating point number because it is an integer
> > 25 is not a floating point number because it is an integer
> > 7 + 3i is not a floating number because it is a complex number
> > 8 + 5i is not a floating number because it is a complex number.
> >
> > Is 3.0 a floating number ? It is a rational number, not an integer right ?

As Steven pointed out the distinction you need to get is floating vs fixed
Scientific notation is a good analogy to understand.

3 looks smaller than 30000000000000000000000
Not so much in scientific notation:

>>> "%g" % 3
'3'
>>> "%g" % 300000000000000000000
'3e+20'
>>>
In effect the position of the decimal point is captured but not the presumably
non-significant digits

Note this is an analogy. Unfortunately in practice…

>
> In a computing context, data types are incredibly significant.

…in practice data types and in particular numeric data types in most
mainstream languages is a total mess.
And becoming an effective programmer means learning to live with/around it.

Some indications of the mess:
>>> .1 + .1 == .2
True
>>> .1 + .1 + .1== .3
False

To get a clue why:
>>> .5 . as_integer_ratio()
(1, 2) # ie ½
>>> .25 . as_integer_ratio()
(1, 4) # ie ¼
>>> .1 . as_integer_ratio()
(3602879701896397, 36028797018963968) # ie OOOOPPPS!!

Another (and in my opinion bigger) violation that most programming languages
including python make over standard math is that fundamental subset relations
are brazenly violated and then duct-taped-over with something called časting’

ie in math we have
ℕ ⊂ ℤ ⊂ ℚ ⊂ ℝ

In programming float, int are all disjoint
That disjointness is bandaided with casts
These should be in principle reversible

>>> x = 10
>>> float(x)
10.0
>>> int(float(x))
10
>>> int(float(x)) == x
True

# So far so good

>>> y = 1000000000000000000000000000000000000000000000000000000000000000000000
>>> float(y)
1e+69
>>> int(float(y)) == y
False

# WTF?! Lets see why...

>>> int(float(y))
1000000000000000072531436381529235126158374409646521955518210155479040L

tl;dr Donald Knuth, is considered one of the greatest programmers. Its a good
idea to follow his example.

In writing Tex he went out of his way to implement his own fixed point
system and avoid using the builtin hardware floating point
https://en.wikipedia.org/wiki/TeX#Development

To the extent its feasible it’s advisable to follow the example of Knuth
[No not writing your own system, but avoiding when/if possible]

[Lawrence D’Oliveiro]

On Sunday, July 31, 2016 at 3:21:09 PM UTC+12, Rustom Mody wrote:
> In writing Tex he went out of his way to implement his own fixed point
> system and avoid using the builtin hardware floating point
> https://en.wikipedia.org/wiki/TeX#Development
>
> To the extent its feasible it’s advisable to follow the example of Knuth
> [No not writing your own system, but avoiding when/if possible]

This is why IEEE-854 was developed, and why Python has the Decimal type <https://docs.python.org/3/library/decimal.html>.