Hi Mark,
What you have illustrated is precisely why JB was experiencing this
problem in the first place (and precisely why most languages do not try
to do anything clever when asked to truncate floating-point numbers).
Due to the need to approximate floating-point numbers with a finite
precision,
Mark-
Sunday, October 9, 2005, 4:58:45 AM, you wrote:
> The solution to the issue you have here is to always add a small
> 'epsilon' value to your numbers before truncating.
Sorry, Mark, but that won't do it.
on mouseUp
local tValue
put 179.71578291 into tValue
put trunc(tV
On 10/9/05 7:41 AM, "Mark Waddingham" <[EMAIL PROTECTED]> wrote:
> Floating-point arithmetic (which Revolution uses) works entirely in base
> 2. However, while all decimal integers have an accurate representation
> in binary, not all decimal fractions do and this is where the
> approximation error
sez [EMAIL PROTECTED]:
>I'm still trying to figure out how something as simple as ((36-34.2)*100)
>can be anything but 180, or how (as Alex put it) "the binary double
>precision representation of 34.2 is inexact"...
Perhaps a few details will help clear up this question.
.1 binary = .5 decim
Hi JB,
> get ((36-34.2)*100)
> put it & cr & trunc(it)
Revolution has a 'numberFormat' property that determines to how many
decimal places are used when numbers are converted to a string.
The difference you are observing here is that the first line is the
string representation of 'it' to (II
> Computers are the servants of humans, not the other way around.
Computers only do precisely what they are told and, unfortunately, it is
not always possible to instruct them to do things in a single way that
satisfies everyone 100% of the time.
Indeed, in cases where you might have a dozen diff
Mark,
Thanks for your explanations.
I fully understand the reasons why trunc((36-34.2)*100) returns 179.
Nevertheless, I still don't understand why the following :
get ((36-34.2)*100)
put it & cr & trunc(it)
returns :
180
179
at least javascript is less confusing, since ((36-34.2)*100)
Indeed, I believe MS Excel and most financial applications use a Decimal
or BCD representation for arithmetic (or use floating-point in such a
way to ensure the results are equivalent).
Floating-point arithmetic (which Revolution uses) works entirely in base
2. However, while all decimal integers
I strongly agree that 'trunc' should come with a warning in the
documentation as to its nature. Indeed, the corresponding function in
perl (int) is documented quite clearly:
"You should not use this function for rounding: one because it truncates
towards 0, and two because machine representations
Hi JB,
The solution to the issue you have here is to always add a small
'epsilon' value to your numbers before truncating.
What is manifesting itself here is the innate approximation methods used
by floating-point arithmetic, combined with the fact the trunc function
does not shield you from thes
Richard Gaskin wrote:
Maybe not. We know, for example, that Excel already accounts for this
in its own code, correcting for the critical failure of the
microprocessor designers. Anyone have time to check if RB, VB, and
others do too?
Python doesn't - though since it's a strongly typed (tho
Richard Gaskin wrote:
I believe the difference between accepting "179" from a computer when we
all know the answer is "180" and accidentally enabling a robot to
violate Asimov's Three Laws is one of degrees, not absolutes.
Probably explains why my Roomba doesn't 'get the corners' too well.
H
other environment tested : javascript
IE 5.01 Mac OS9
(36 - 34.2) * 100->179.7
Math.floor((36 - 34.2) * 100)->179
IE 6 Win XP
(36 - 34.2) * 100->179.71
Math.floor((36 - 34.2) * 100)->179
Firefox 1.0 Win XP
(36 - 34.2) *
Richard Gaskin <[EMAIL PROTECTED]> wrote:
> > Bring BCD , that's what I say :-)
>
> "BCD"?
Binary Coded Decimal?
In the ancient times ;-)
there were TWO versions of Microsoft Basic, one of them was a BCD
version for accounting!
Not for saying that this problem is a long time one ;-))
--
On 10/8/05 9:47 PM, "Richard Gaskin" <[EMAIL PROTECTED]> wrote:
>> You might get Rev to introduce a workaround (e.g. by changing the
>> effective meaning of trunc() to be "round at some ;eve; of precision
>> that will do what I *want*, and then truncate", as Mark suggested) - but
>> I fear that on
Alex Tweedly wrote:
Richard Gaskin wrote:
Computers are the servants of humans, not the other way around.
You wish !!
I know you well enough to know you're just having fun there, but because
this anomaly has been accepted as "normal" in microprocessor design I
hope the readers here will i
Richard Gaskin wrote:
One man's "artifact" is another man's "bug". :)
The original poster never specified that it was a Rev bug,
The *original* poster (jbv) didn't, but Jonathan (to whom I was
replying) did. At least, he said that Rev did this, and he said (in an
earlier email) that it wa
Alex-
Friday, October 7, 2005, 11:14:47 AM, you wrote:
> It's NOT a Rev bug - it's an artifact of double precision binary
> arithmetic (or, if you like, an artifact of the IEEE format used by
> Intel (and everyone else)).
I'm sure if I coded the same thing in java I would also come up with
179.
Hi all,
set the numberformat to "0.0"
put (36-34.2)*100 into temp
put temp & cr & trunc(temp) & cr & trunc(180)
Result:
180.0
179.0
180.0
Difficult to name this a man's bug ;-)
Le 8 oct. 05 à 03:41, Richard Gaskin a écrit :
Alex Tweedly wrote:
Lynch, Jonathan wrote:
But s
Alex Tweedly wrote:
Lynch, Jonathan wrote:
But still...
Answer trunc((36-34.2)*100) should return 180, not 179.
No it shouldn't.
I mean, the
underlying code should work to return an accurate value.
It does.
Perhaps it is just a matter of opinion, but to me, if the software
returns a wr
FWIW:
In MS Excel (v.97, on Windows), "=TRUNC((36-34.2)*100)" gives 180.
:-)
Curry Kenworthy
Curry K. Software
http://curryk.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and man
On 10/7/05 2:30 PM, "jbv" <[EMAIL PROTECTED]> wrote:
> Nevertheless, how do you explain that the following :
>
> put 36 into A
> put 34.2 into B
> put A-B into C
>
> put C*100 into C
> put trunc(C)
>
> returns 180 with Rev 2.5 on Mac OS9, but returns 179 on other
> platforms such as L
jbv wrote:
Nevertheless, how do you explain that the following :
put 36 into A
put 34.2 into B
put A-B into C
put C*100 into C
put trunc(C)
returns 180 with Rev 2.5 on Mac OS9, but returns 179 on other
platforms such as Linux or Win2000 ?
Just curious...
I was curious about that too
Alex,
> Users of trunc() (whichever language they use it in :-) should be wary
> of the dangers.
>
Thank you so much for your explanations. As for rev users, I strongly
suggest that this "potential problem" should be mentioned in the doc,
at least in the part dedicated to the trunc() function..
>It's NOT a Rev bug - it's an artifact of double precision binary
arithmetic >(or, if you like, an artifact of the IEEE format used by
Intel (and >everyone else)).
Alex, your explanation makes perfect sense, and I accept that it is not
a Rev bug.
But...
I still don't like it, though.
This affe
Lynch, Jonathan wrote:
But still...
Answer trunc((36-34.2)*100) should return 180, not 179.
No it shouldn't.
I mean, the
underlying code should work to return an accurate value.
It does.
Perhaps it is just a matter of opinion, but to me, if the software returns a
wrong
value in a cal
AM
To: How to use Revolution
Subject: Re: Strange math behaviour... could someone explain this ?
Lynch, Jonathan wrote:
>Even just this simple line produces the same error:
>
>Somehow, Rev is performing 36-34.2, and even though it displays that
>number as 1.8, it must be processing i
behaviour... could someone explain this ?
Lynch, Jonathan wrote:
>Even just this simple line produces the same error:
>
>Somehow, Rev is performing 36-34.2, and even though it displays that
>number as 1.8, it must be processing it internally as
>1.799 or some
179
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of jbv
> Sent: Friday, October 07, 2005 10:02 AM
> To: How to use Revolution
> Subject: Re: Strange math behaviour... could someone explain this ?
>
> According to my tests (which aren
get 179
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of jbv
> Sent: Friday, October 07, 2005 10:02 AM
> To: How to use Revolution
> Subject: Re: Strange math behaviour... could someone explain this ?
>
> According to my tests (which are
Lynch, Jonathan wrote:
Even just this simple line produces the same error:
Somehow, Rev is performing 36-34.2, and even though it displays that
number as 1.8, it must be processing it internally as
1.799 or something like that.
Very disturbing - This could affect a prog
-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of jbv
> Sent: Friday, October 07, 2005 10:02 AM
> To: How to use Revolution
> Subject: Re: Strange math behaviour... could someone explain this ?
>
> According to my tests (which aren't exha
I just tried this script - but I still get 179
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jbv
Sent: Friday, October 07, 2005 10:02 AM
To: How to use Revolution
Subject: Re: Strange math behaviour... could someone explain this ?
According to my tests
According to my tests (which aren't exhaustive)
there seems to be another workaround :
put 36 into A
put 34.2 into B
put A-B into C
put C*100 into C
put trunc(C)
this gives 180 as a result, while the following line
(replacing the last 2 of the above example) gives 179
put trunc(C*10
?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lynch,
Jonathan
Sent: Friday, October 07, 2005 9:32 AM
To: How to use Revolution
Subject: RE: Strange math behaviour... could someone explain this ?
Even just this simple line produces the same error:
answer
behaviour... could someone explain this ?
I get the same thing...
That's gotta be a bug.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jbv
Sent: Friday, October 07, 2005 7:17 AM
To: How to use Revolution
Subject: Strange math behaviour... could
I get the same thing...
That's gotta be a bug.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jbv
Sent: Friday, October 07, 2005 7:17 AM
To: How to use Revolution
Subject: Strange math behaviour... could someone explain this ?
Hi list,
exam
Hi list,
example 1 :
put 1.8 into myA
put trunc(myA * 100) into myA
in that case, myA=180which is OK
--
example 2 :
put 34.2 into myA
put 36 into myT
if myA > 0 then
if myA < myT then
get myA
put myT - myA into myA
put it into myT
else
38 matches
Mail list logo
