Op Sun, 28 Oct 2007, schreef Milan Marusinec:

If you do on a hand calculator:

1/3

... you will see:

0.33333333333

If you multiply again with 3, you will see:

0.99999999999

... and not 1.00000000000.

There is a similar issue here. The value "0.4" cannot be stored exactly in a computer, therefore it is rounded.

This behaviour normal and while annoying, it is simply how things work in the digital world, you will have to work around it.

Daniël

Or, of course, use a scaled integer type like Currency.

Op Sun, 28 Oct 2007, schreef Joao Morais:

This is indeed a question you should ask, but you should generalize it. In mathematics we consider several groups of numbers:

N - Natural numbers
Z - Integer numbers
Q - Rational numbers
R - Real numbers
C - Complex numbers

Subranges of N, Z and Q can be represented exactly in a computer. R and C can not, we use the floating point system as approximation. Very often, a certain calculation that on the first sight might tempt one to use a real, can be performed in N or Q. In such case floating point is overkill and thus, you can save yourself a lot of trouble by calculating it in N or Q.

Daniël

Hello folks,

This one looks pretty elementary, but to my big surprise it doesn't work as I would expect.

I'd like to ask FreePascal compiler creators, how can I safely evaluate double variables in case like this.

Sample program with comment is in attachement ...

Milano

They calculate usually internally with more digits than they display or they even might use bcd numbers which makes the program working with fpc as well:

//
// Hm. This is really weird. I assign 1 to x, which is of double type.
// Then I add 0.4 to the x, then I subtract 0.4 from x.
// So, now I should have 1 in x. But when I compare x with 1, I get
// wrong evaluation of "if x = 1 then" statement !
//
// I tried this on two different Windows Intel machines and it was wrong.
// I tried it also on Mac with PowerPC processor and it was also wrong.
// (Both Delphi & FPC compilers)
//
//
//
program
 floating_error_1_4 ;
 uses
   fmtbcd;
{$APPTYPE CONSOLE }
var
 x : TBCD;
BEGIN
 x:=1;
 x:=x + 0.4;
 x:=x - 0.4;
 if x = 1.0 then
  writeln('OK: x = 1 ' )
 else
  writeln('Error: "if x = 1" is evaluated wrong !!!! ' );
END.

Op Sun, 28 Oct 2007, schreef L:

It isn't smarter, but it has more digits. Press the "pi" button and subtract the number you see in your display. That'll reveal how many digits your calculation uses.

Regarding the $3000 computer: An extended has 20 digits of precision. Make sure you round your output to 10 digits and you need to a very weird calcation until you can see a rounding difference :)

Daniël

It shows the current weak state of the dollar. Look what 3 and an half euro is worth nowadays:

  writeln(3E5:10:3);

:-)

On my electronic/digital calculator I see '1'

It is a casio fx-300SA

Maybe $5 digital calculators are smarter than $3000 computers ;)

Regarding the $3000 computer: An extended has 20 digits of precision. Make sure you round your output to 10 digits and you need to a very weird calcation until you can see a rounding difference :)

I was talking about $3000 pascal dollars:

BEGIN
  writeln($3000);
END.

Output:
12288

The Pascal dollar is worth a lot more than you think.

This is big nonsense. The issue is not if they can be "represented in a computer" but that a 10-base decimal fraction can not be represented exactly in a 2-base floating point format.

Regards,

Adriaan

Op Sun, 28 Oct 2007, schreef Adriaan van Os:

Why? There exists no data structure that can hold any number from R or C.

The issue is not if they can be "represented in a computer" but that a 10-base decimal fraction can not be represented exactly in a 2-base floating point format.

Indeed, and this is because the 2-base floating format is an approximation of R, while the datatype name "real" gives the impression that the datatype can hold the real numbers.

Daniël

This behaviour normal and while annoying, it is simply how things work in the digital world, you will have to work around it. Daniël

oh yes, this is one of the possible workarounds:

function is_equal_dbl(a ,b : double ) : boolean;
const
 epsilon = 1e-14;
begin
 result:=Abs(a - b ) < epsilon;
end;

It's just one more funny thing one must realize,
when comparing real numbers with some exact
real constants. After this, I will try to never
compare doubles directly, but using tricks like
above. Because, in this digital world
1 + 0.4 - 0.4 1.

Milano

The programmer definitely should care. He has to make the right choice in what type he chooses, so he must be aware of any 'quircks' of the type he is using, and that includes how things are rounded and how they are stored in memory. That's why there are IEEE references for this.

It's his job to make sure that the end user gets something sensible on the screen, and that includes rounding to a usable number of digits.

The currency type calculates with a certain precision for you if you really don't want to be bothered with the gory details. The opposite side of the medal is that it's limited to 4 digits, and cannot be larger than 2^59 or thereabouts.

Michael.

It's not about digital vs analog, it's about limited precision. And you simply cannot ignore that, unless you only use extremely high level primitives. For example, when adding a bunch of floating point numbers, you should sort them from small to large because otherwise you lose a lot more precision. So unless you use an "AddFloat (realarray, count): float" function, you also have to care.

For example, my calculator subtracts 0.4 just fine, and it is digital!

It has been explained earlier in this thread why that is so.

Then they should not use floating point in programming languages, but Mathlab, Maple, or special purpose libraries/types.

Jonas

Op Mon, 29 Oct 2007, schreef L:

Your Casio doesn't do comparisons. Just round to 10 digits before you compare and it'll work just as fine as on your Casio.

Daniël

Currency should do fine, as long as you don't need more than 4 decimal places.

Michael.

Op Mon, 29 Oct 2007, schreef L:

It means it displays 10 and has 2 additional digits for internal use. As I said, the easiest way to check this is to push the pi button and subtract the number you see in the display. If remember well some Casio calculators also have a button to truncate the internal digits.

Daniël

My opinion:
This is ludicrous.

The end user is using a high level language and should not care whether the computer is digital or analog.

For example, my calculator subtracts 0.4 just fine, and it is digital!

I don't care about decimal points or any other excuses. THe fact is people expect languages on computers to work like their calculator does or like how grade school math worked.. simple, sensible.

1 minus 0.4 is 0.6. We need a Type to solve this problem if there isn't already one using currency or the suggested units. We are using high level languages here, not assembly code for creeps sake.

Maybe currencies or the unit suggested by Florian solves the (IMO) ludicrous problem of todays languages. Imagine if we could not send emails because 'digital computers don't store text, they just store numbers, so you'll have to send your mail using numbers Sir'.

L505

Unfortunately, there is a problem. One can try to hide it (as calculators attempt to do), but in the longer run that is going to be unsuccessful and even dangerous.

The mathematical structures of floating point numbers and of real numbers do not match, and cannot be made to match faithfully.

See e.g. any good textbook on numerical mathematics. However, most of those texts are not so accessible to the layman. I have written a short article on it for secondary educations, that I hope is more accessible:

Gyula Horvath, Tom Verhoeff.
``Numerical Difficulties in Pre-University Informatics Education and Competitions'',
Informatics in Education, Vol. 2, Number 1, pp.21-38. <http://www.win.tue.nl/~wstomv/publications/INFE012-final.pdf> URL checked OK

(Sidenote: If your program only needs to deal with decimal fractions, then it is stronly advised not to use Real/Single/Double, but e.g. Currency. Floating-point numbers are useful in scientific and engineering applications.)

Tom

Agree.

As long as there is some type where you can treat the language like a regular old dumb casio calculator that was used in grade school math, then I'm happy. I haven't done much currency work or float work with Pascal and wanted to confirm there was at least a dumb/simple high level decimal type out there somewhere for when you need one ;-)

L505

Your Casio doesn't do comparisons. Just round to 10 digits before you compare and it'll work just as fine as on your Casio. Daniël

And some off topic trivia:

My casio says "10 + 2 digits" near the model number.

Does this mean it displays 10 digits and stores 2 in the background, or that I can somehow scroll and access these 2 digits? I should RTFM but thought you folks might know.

Op Mon, 29 Oct 2007, schreef L:

Same as ansistring.. it can be dangerous to hide all the intricate details of a pchar/bytearray, which is what ansistring does. But ansistrings are really useful for 'every day' use.

Wrong. A string can be represented "alphadequate", as it is called; an ansistring can handle any string you can imagine supposed there is enough memory available.

An adequate or alphadequate representation of a real number cannot exists. Regardless what datastructure you use, there always exists a real number that cannot be represented by it.

My point mainly was that we have high level types like ansistrings, so why not have good decimal type that acts just like a calculator. Could be called 'TCasio'. Don't call it that, I'm kidding on the type name.

Feel free to make a proposal.

Daniël

In binary that is 00000001 + 0.0110011001100.... - 0.0110011001100.... because we hit recurring decimals a lot more in binary than decimal. I wonder why we don't have a standard format (maybe we do?) that factors in the remainder as part of the number also? 4 bits with recurring fraction ("decimal") debugging power could do some good. Maybe it's just too messy and slows FP operations even more. Would think that 0000 for recurring length too big, 0001 for no recurring, and 0010-1111 (2-15) would be length of recurring bits from lsb. Not sure if one would be able to detect longer easily. That would be able to cover 4 decimal digits of repeating bits.

0.0110011001100 (was 4/10)
+ 0.0110011001100 (was 4/10)
+ 0.0011001100110 (was 2/10)
= 0.1111111111111 (was 10/10)
(0.0000000000001 short)

With the above, they all repeat on 4 bits:
1100
1100
0110
=11110 - this would translate to a series of 1s if recurred. Would here be able to surmise that we need to add the 0001 that is short. because the recursion has been undone. It would probably lead to a pile of new problems but, that's another story.

Stephen
*-----------------------------------------------------------------------

This E-Mail may contain confidential and/or privileged information. It is only intended for the use of the addressee indicated in this message. If you are not an intended addressee of this email (or responsible for delivery of the message to such person), the disclosure, copying or delivering of the contents of this email to anyone else is strictly prohibited and may be unlawful. If you receive this e-mail by mistake destroy the message and please notify us immediately by e-mail,

Information or opinions in this message that do not relate to the business of ELCB Information Services shall be treated as neither given or endorsed by it.

*-----------------------------------------------------------------------

Op Mon, 29 Oct 2007, schreef Stephen Dickason:

The answer can be found in the fact that any number with recurring decimals is a rational number and therefore does not need floating point numbers.

Daniël

Same as ansistring.. it can be dangerous to hide all the intricate details of a pchar/bytearray, which is what ansistring does. But ansistrings are really useful for 'every day' use.

It took about 30 years for someone to finally invent the ansistring because all those other people thought that something like an ansistring would be too slow/dangerous on the current hardware available. And maybe back then it was. So we used Pchar and 255string and it limited our thinking back then (and I wasn't born back then in the 70's so I shouldn't talk, but I've looked over history and can see patterns).

Eventually, people realize that programming languages should be 'easy to use' by default, and learn that you should be able to escape this 'easy to use' system by using other types or turning off switches (i.e. range checking, {$H+} etc.). So my point is.. I hope we have solutions.. and we do.. currency and others. Currency just seems to be kind of hack compared to something more like a TCasio would be.. We should have something like that. Most people that use programming languages are using them as general purpose tools... and if they want to do engineering then they can pull in the engineering library in their uses clause. But by default, we should have TCasio available. Currency seems to be close.. but maybe not close enough to a casio calculator. Plus, it's called currency.. which is dedicated for currency, not calculating every day math (patches welcome, yes yes I know).

My point mainly was that we have high level types like ansistrings, so why not have good decimal type that acts just like a calculator. Could be called 'TCasio'. Don't call it that, I'm kidding on the type name.

Lately during parsing I've had to defeat the compiler by using uniquestring and setlength.. but ansistrings are still worth it because in general this is what people need to be doing.. adding/concatenating strings of unknown final lengths ;-)

I assume in general, pascal is used for every day programming.. not scientic computing. I assume that most people would want to do every day math like on a Casio calculator.. and only some people would want to do engineering.. so those folks can pull in the engineering units when they need to.

I will download and read, thanks.

(Sidenote: If your program only needs to deal with decimal fractions, then it is stronly advised not to use Real/Single/Double, but e.g. Currency. Floating-point numbers are useful in scientific and engineering applications.)

Absolutely agree and was the point I was trying to make.. there are some times when you just want a computer to concatenate strings.. and there are times when you really want the computer to act like regular old calculator. So we shouldn't limit our thinking to 255 strings and shouldn't limit our thinking to floats/extended/double. We should have floats/extended/double available and 255 strings available for when we need them.. but maybe we should also have a TCasio and Currency available too.

Mainly, it seems now my point is that we have a 'currency' type that maybe isn't the best we could have.. and quite possibly we are limiting our thinking around this currency type and these float types. Remember back when 255 string was 'the thing' to use.. and no one would possibly think of an ansistring since it didn't exist at the time and couldn't POSSIBLY be useful to use since 255 was enough.. or that pchars were enough when 255strings weren't fit?

Just being devils advocate as always.. trying to encourage creative thought and invention..

Lars

Stephen Dickason wrote

In binary that is 00000001 + 0.0110011001100.... - 0.0110011001100.... because we hit recurring decimals a lot more in binary than decimal. I wonder why we don't have a standard format (maybe we do?) that factors in the remainder as part of the number also?

It's possible to create a type that stores the numerator and denominator, but then you would need to "simplify" to extract common factors on every calculation, otherwise it would quickly run out of range (Integer or whatever you choose). Extracting common factors takes exponential time, so it's quite slow. The range would be quite limited as well, it's as wide as the numerator.

Micha

Yes, but how long does it take? 1ms? 10ms? People will even complain if it takes more than 1ns on a PC in contrary and even more about the blow of the system unit growing by the size of the fmtbcd unit ;)

Probably -4*10-10 :)

Another funny thing is:
Enter sqrt(sqrt(sqrt(1.000000001))) and you've 1 in the display. Then calculate this Result^1e10. I wonder if 1^1e10=3.000...(on my Casio) is what you call intuitive ;)

Unfortunatly I don't use calculators that much any more, but during my school time I knew a lot of waysto crash, fool or whatever calculators. During school time we had one (was in the 90s, a simple Casio) which could be send into an endless loop with some easy calculation, I don't remember how though :(. While doing this, it turned off the display and looked off, but sucked a lot of power because it was still calculating. Guess what we prefer to do with the teacher's calculator, he never got an idea why the batteries of his caluclator were permanently empty :)

If remember well some Casio calculators also have a button to truncate the internal digits.

In fact, the GMP (GNU Multiple Precision Arithmetic Library <gmplib.org>) offers this and more. Unfortunately, there does not seem to be a complete FreePascal interface for it. Maybe it is easy to adapt (if necessary?) the GNU Pascal interface for GMP <http://www.gnu-pascal.de/gpc/GMP.html>. I would be interested.

There is also an initial attempt <http://fjf.gnu.de/misc/gmpop.inc> to make the GMP functions available as operators under GNU Pascal. The (ultimate) goal is that you can simply write things like r := (a + b) * c where a, b, and c have a GMP number type, instead of writing things like mpq_add ( r, a, b ) ; mpq_mul ( r, r, c ) .

Tom

Op Mon, 29 Oct 2007, schreef L:

Noted. Perhaps the reason is it is written with an alpha sign in my books.

This is the difference between adequate and alphadequate. Alphadequate="supposed there is enough memory available". Supposed you have enough memory, you can store any string.

On the other hand a Pascal boolean is adequate for storing a mathematical boolean, regardless how much memory you have.

And, as said before, no datastructure is adequate for storing a mathematical real number. Not even if you have infinite memory.

Daniël

Yes, that's what happens on mine.

> Unfortunatly I don't use calculators that much any more, but during my > school time I knew a lot of waysto crash, fool or whatever calculators.

The kids in my advanced math class would play a game called 'Drug Wars' or similar on their calculator.. even during exams. They'd copy the answers from me when they realized they'd been playing Drug Wars on their Ti-83's and didn't have time to complete their assignment.. ticked me off but for some reason I let them copy my answers. Probably so they'd remain dumb for the rest of their life. I just used my casio and never purchased any special calculators for advanced math class. Of course people would also use Ti-83's to store text information for cheating.

L505

Same as ansistring.. it can be dangerous to hide all the intricate details of

a

http://www.google.ca/search?q=alphadequate

Your search - alphadequate - did not match any documents.

Suggestions:
-Make sure all words are spelled correctly.
-Try different keywords.
-Try more general keywords.
-Tell Google they are wrong with a capital w.

An adequate or alphadequate representation of a real number cannot exists. Regardless what datastructure you use, there always exists a real number that cannot be represented by it.

A string with infinite characters cannot be represented. Therefore, there is always a string that cannot be represented.

RealToStr() for example.

Daniël Mantione wrote

And, as said before, no datastructure is adequate for storing a mathematical real number. Not even if you have infinite memory.

Nope. If infinite memory was tangible, you would be able to store any real number.

But there are multi-precision libraries for Free Pascal.

The one I am writing:
"NX" (big integers, big reals, big complexes, big polynomials over GF(2)) at
http://www.ellipsa.net/

An other one:
"MPINT" (big integers, big rationals) at
http://home.netsurf.de/wolfgang.ehrhardt/misc_en.html#mpint

And there are others.

mm

How many time would it take to store Pi in an infinite memory? :-)

mm
http://www.ellipsa.net/

1, off course.

Yes, only *one* eternity.

mm
http://www.ellipsa.net

But someone tried to reproduce the example with other programming languages?

mm ha scritto:

A copy-paste from Python Shell:

>> a = 1 >> a

1

>> a = a + 0.4 >> a

1.3999999999999999

>> a = a - 0.4 >> a

0.99999999999999989

>> a == 1

False

Best regards
Inga

PS I always talk to my informatics-students: You never-ever do with real-variables something like this: if real1 = real2 then ... Real numbers can be equal with some precision.

The discussion about PI reminds me another funny quote:

The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change. -- FORTRAN manual for Xerox Computers

Oh, my GOD!
I hope, in the current eternity, no change in the value of pi might occur!

Or a bit more simple (and for some maybe even more surprising):

>> 1.0 == 0.4 - 0.4 + 1.0

True

>> 1.0 == 1.0 + 0.4 - 0.4

False

Floating points are not "real"s. Even simple commutative laws don't hold.

Vinzent.

Here is another funny pi quote (appearing in a footnote in a book on VLSI design):

"pi = sqrt(10) for small values of pi"

With apologies for the increasing off-topicness,

Tom

Musan Antal wrote

Oh, my GOD! I hope, in the current eternity, no change in the value of pi might occur!

I bet the circles will never will be the same if that happens.:P

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal