Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

El mar, 30-10-2007 a las 19:36 +0200, Musan Antal escribió: > > 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 -

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ? (more pi fun)

On Tue, Oct 30, 2007 at 07:36:39PM +0200, Musan Antal wrote: > 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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ? (GMP)

On Tuesday 30 October 2007 17:31, Inga Petuhhov wrote: > A copy-paste from Python Shell: > >>> a = 1 > >>> a > > 1 > > >>> a = a + 0.4 > >>> a > > 1.3999 > > >>> a = a - 0.4 > >>> a > > 0.99989 > > >>> a == 1 > > False Or a bit more simple (and for some maybe even more surp

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ? (GMP)

A copy-paste from Python Shell: a = 1 a 1 a = a + 0.4 a 1.3999 a = a - 0.4 a 0.99989 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 c

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ? (GMP)

But someone tried to reproduce the example with other programming languages? mm ha scritto: Tom Verhoeff a écrit : In fact, the GMP (GNU Multiple Precision Arithmetic Library ) offers this and more. Unfortunately, there does not seem to be a complete FreePascal interface for it. Maybe it

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

Germán Pablo Gentile - PetroBox a écrit : El mar, 30-10-2007 a las 02:28 +0100, mm escribió: Joao Morais a écrit : 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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

El mar, 30-10-2007 a las 02:28 +0100, mm escribió: > Joao Morais a écrit : > > 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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

Joao Morais a écrit : 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. How many time would it take to stor

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

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. -- Joao Morais __

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ? (GMP)

Tom Verhoeff a écrit : In fact, the GMP (GNU Multiple Precision Arithmetic Library ) 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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

> 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 stri

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

> 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. > > Probably -4*10-10 :) Yes, that's what happens on mine. > > Unfortunatly I don't use calculators that m

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ? (GMP)

On Mon, Oct 29, 2007 at 06:36:11PM +0100, Micha Nelissen wrote: > > 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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

Daniël Mantione schrieb: > > 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 >> >> And some off topic trivia: >> >> My casio says "10 + 2 digits" near the model num

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

L schrieb: >> 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. > > My opinion: > This

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

Stephen Dickason wrote: > In binary that is 0001 + 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 po

RE: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

Op Mon, 29 Oct 2007, schreef Stephen Dickason: > > 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 >

RE: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

> 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. In binary that is 0001 + 0.01100110

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

> > > > The end user is using a high level language and should not care whether the > > computer is digital or analog. > > 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. Same

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

On Mon, Oct 29, 2007 at 07:30:03AM -0700, L wrote: > > 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 >

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

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 > > > And some off topic trivia: > > My casio says "10 + 2 digits" near the model number. > > Does this mean it d

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

On Mon, 29 Oct 2007, L wrote: > > > 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 th

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

> 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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

Op Mon, 29 Oct 2007, schreef L: > > 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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

On 29 Oct 2007, at 15:30, L wrote: 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. My opinion:

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

> 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

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

On Mon, 29 Oct 2007, L wrote: > > 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 <

Re: [fpc-pascal] Re: Why this evaluates on "if" wrong ?

> 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. My opinion: This is ludicrous. The end