Re: bug in remainder ?

new topic     » goto parent     » topic index » view thread      » older message » newer message

Daniel Johnson wrote:

>Thanks for that extract Rett, which explains all.
>
>However here we have a problem. If remainder does not work properly with
>floating point numbers it should only accept integers, or there should be a
>work around. I have to use C++ here so if I want to use a clunky language
>where I am constantly forced to think of such things I can use that. Euphoria
>is here to set us free from having to think like a machine, and in that sense
>this could be considered a bug, albeit a documented one. Can the eccentric
>millionaire figure out a workaround for this ?
>
Not to defend a side-effect of my least favorite aspect of Eu, but the problem
with floating point decimals not adding up to the sum of their parts is as
old as computing. We had the problem in Fortran programs in 1966 on the
CDC 6600 that I cut my teeth on. The only way to avoid it is to reformulate
every piece of math using decimals to use integers and do divides...which
were then and are now the slowest instructions on many computers. With modern
integer ALU's processing almost all instructions in less than one
cycle, the issue is no longer as critical. The transformation, however, is
quite expensive in program logic. With a compiler that only has to do the
transformation once for many runs of an object program, the issue is not
germane. With an interpretive or compile and go system like Eu, it can
put a real kink in performance. If computers were decimal systems, the
problem would be trivial, but binary math just does not map one on one to
base ten math. I am convinced that COBOL programs became the dominant
accounting language base because of IBM's use of the packed decimal
instruction set in their mainframes. This allowed people to do normal
decimal math with little consideration for the binary nature of computer
storage.

The problem with Eu in this situation is expectations. Since we are not
supposed to know the internal format of data, we tend to take a WYSIWYG
attitude towards the data that we use. Unfortunately, it ain't so and this
isn't the only situation where this occurs. It also exposes the thinness of
the Eu documentation. Much is left to surmise or experiment. This
particular item is easy to test and expose. Other items are less so.

Everett L.(Rett) Williams
rett at gvtc.com

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu