Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91375
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error)
To: internals@lists.php.net
References: <CAF+90c_1zO91x-4Madqm3F8gkKDT7jZKVZSbBuYMbnDCADrv_A@mail.gmail.com>
 <47.95.38634.798BCC65@pb1.pair.com> <56CCFDD2.4000102@gmail.com>
 <A0.38.38634.0530DC65@pb1.pair.com>
Message-ID: <56CD98F9.8020802@lsces.co.uk>
Date: Wed, 24 Feb 2016 11:50:17 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <A0.38.38634.0530DC65@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1
From: lester@lsces.co.uk (Lester Caine)

On 24/02/16 01:11, Andrea Faulds wrote:
> Furthermore, if PHP developers find floating-point confusing and are
> genuinely surprised that 0.1 cannot be represented in binary exactly,
> then perhaps they should go and learn about what floating-point numbers
> do, rather than naïvely continuing on thinking they're decimals thanks
> to PHP lying to them! It is not the job of the language to try and hide
> that floats are imprecise from programmers.

This just about sums up my understanding on the differences between a
programmer and a software engineer. There are fundamental limits to each
of the different hardware platforms one is running code on, so
'assuming' that the answers you get are always the same simply proves
one still has to learn how to program. SQL addressed many of these
differences early on, and things like fractional currency fields being
managed as integers with a fixed fractional offsets ( NUMBER(8,3) )
which accurately record 'tenth of a cent' provide clean interfaces, but
all too often they get transferred into 'float' because it's 'easier to
handle'. That PHP makes some of these conversions transparently *IS* the
problem of the language, but often it's because the programmer is simply
ignorant of why the original methods were adopted?

BIGINT is an example of where there are different understandings of just
what a number is, and trying to add unlimited accuracy is not a
substitution to the fact that when accessed from a database a BIGINT is
simply a clean 64bit number. Float has the same limitations based on
just what hardware is providing it?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk