The problem is probably in log.
1000.0d log = 3.0d.
returns false!!!

The comment of Double>>#fractionPart clearly states "Answer a Double
whose value is the difference between the receiver and the receiver's
truncated value". So there's nothing wrong with #fractionPart.

The problem is probably in log.
1000.0d log = 3.0d.
returns false!!!

There's nothing wrong with that. It is just an example for the fact
that logarithms are usually computed up to a certain precision, and
that the precision of Doubles is limited. The difference is really
small:
1000.0d log - 3.0d ==> -4.4408920985006d-16

Cheers,
Joachim Geidel

A few years back, Intel had to spend $500M to recall a bunch of
Pentium chips that has small errors. I think Cincom would do well to
look into this bug before J P Morgan loses a few million dollars in
their business because of the bug.

In mathematics, it is absolutely not acceptable for
1000.0d log to be anything but 3.0d.

A few years back, Intel had to spend $500M to recall a bunch of
Pentium chips that has small errors. I think Cincom would do well to
look into this bug before J P Morgan loses a few million dollars in
their business because of the bug.

In mathematics, it is absolutely not acceptable for
1000.0d log to be anything but 3.0d.

I double the IEEE standard would allow that.

Aik-Siong,

1000.0d log fractionPart
gives 1.0d. It should be 0.0d. The error is not small. Is this a bug?

1000.0d floorLog: 10.0d
gives 2. It should be 3. Again the error is not small. Is this a bug?

1000.0d floorLog10
gives 3 which is correct.

I encountered the above problem while trying to get the base 10
mantissa of a number. How can I do that safely?

1000.0d log fractionPart
gives 1.0d. It should be 0.0d. The error is not small. Is this a bug?

1000.0d floorLog: 10.0d
gives 2. It should be 3. Again the error is not small. Is this a bug?

1000.0d floorLog10
gives 3 which is correct.

I encountered the above problem while trying to get the base 10
mantissa of a number. How can I do that safely?

1000.0 floorLog: 10.0. -> 2.

Aik-Siong escreveu:
1000.0d log fractionPart
gives 1.0d. It should be 0.0d. The error is not small. Is this a bug?

Your perception of the problem it that it is a bug, however, the
implementation of this method is (in Double it calls super, but the
effect is):

Double>>fractionPart
"Answer a Number whose value is the difference between the
receiver and the receiver's truncated value. "

^self - self truncated

Now how truncated works?

Double>>truncated
"Answer a SmallInteger equal to the value of the receive
without its fractional part. Fail if the truncated value be
represented as a SmallInteger. In that case, the code below
will compute a LargeInteger truncated value"

primitive: 571
| max quo rem |
max := SmallInteger maxVal // 2 + 1.
quo := self quo: max asDouble.
rem := self - (quo * max asDouble). "in-line rem to avoid
exponential number of quos"
^quo * max + rem truncated

If you care to check, you'll see that 1000.0d log truncated returns 2
(because 1000.0d log - 3 == -4.4408920985006d-16).


1000.0d floorLog: 10.0d
gives 2. It should be 3. Again the error is not small. Is this a bug?


Same issue, Number>>floorLog: uses Number>>floor which uses truncated.

1000.0d floorLog10
gives 3 which is correct.


As this method uses a primitive, it may be that results are done all in
the math coprocessor where some more guard bits maintain the precision
before sending the result.

I encountered the above problem while trying to get the base 10
mantissa of a number. How can I do that safely?

Unfortunately as Joachim observes there are a few methods you can try
but they're specific for each case.

My bet would be to do something like (you may try use rounded instead):

(1000.0d truncated) floorLog: 10.0d and (1000.0d truncated) log
fractionPart, and see if the errors are amenable with this approach.

HTH

BTW,

1000.0 floorLog: 10.0. -> 2.

I accept that this Dolphin result is in error but at least #fractionPart
is okay.

Best regards

OK Andy!

1000.0 floorLog: 10.0. -> 2.

I accept that this Dolphin result is in error but at least
#fractionPart is okay.

OK Andy!

Now we get back to square one! Given enough test cases it will fail in
border cases, perhaps different from other dialects, but still the same
thing.

Joachim's post still points to the broad answer.

Cesar,

1000.0 floorLog: 10.0. -> 2.

I accept that this Dolphin result is in error but at least
#fractionPart is okay.

OK Andy!

Now we get back to square one! Given enough test cases it will fail in
border cases, perhaps different from other dialects, but still the
same thing.

Joachim's post still points to the broad answer.

Okay, I take it back. I've spent a bit of time looking into the Dolphin
implementation and I can see that (as you predicted) it isn't an easy
fix and using discontinuous functions like floor and round on calculated
floating values is the problem.

Actually, I came across just the same
issue in some tests I wrote the other week and never found a solution. I
should have remembered that and piped down!

Sorry for the interjection - I'm back under my rock now.