Dear Serge,
on the VM mailing list, Levente pointed out, that this could also be
related to some lib the VM uses (e.g., Freetype) that might change the
rounding mode. I'll dig into it and give your idea a try and come back
with the results.
I think it would be nice to have in Pharo 7. But before I want to make
sure it a) works as expected and b) does not cause some nasty side effects.
Bye, Steffen
Am .05.2018, 12:26 Uhr, schrieb Serge Stinckwich
<serge.stinckw...@gmail.com>:
On Thu, May 24, 2018 at 12:27 PM Steffen Märcker <merk...@web.de> wrote:
Hi,
now I've observed the same issue. It might be related to context
switching, since introducing a delay has a similar effect. Consider:
| FE_TONEAREST FE_DOWNWARD FE_UPWARD FE_TOWARDZERO |
FE_TONEAREST := 16r0000.
FE_DOWNWARD := 16r0400.
FE_UPWARD := 16r0800.
FE_TOWARDZERO := 16r0C00.
"For some reasons we have to call fegetround once."
"c := LibC new fegetround."
LibC new fesetround: FE_DOWNWARD.
(Delay forSeconds: 1) wait.
v1 := 1.0/10.0.
LibC new fesetround: FE_UPWARD.
v2 := 1.0/10.0.
LibC new fesetround: FE_TONEAREST.
v1 < v2.
If the delay is inserted, the script evaluates to false. Using the same
LibC-instance or creating a new one does not seem to change anything
here.
Interestingly, a similar approach in VisualWorks does not show this
issue
yet.
Ok, so maybe we need to use put evaluation in a block and use
valueNoContextSwitch ?
Maybe use an API like the one you propose before :
Double roundToMinusInfWhile: [ ... ]
Actually, I expect the FE_* macros to be platform/implementation
dependent, as suggested here:
http://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/c/numeric/fenv/FE_round.html
Ok.
Can we try to pack everything in a PR for Pharo 7.0 ?
Thank you.