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.stinckwich@gmail.com>:
On Thu, May 24, 2018 at 12:27 PM Steffen Märcker <merkste@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/n...
âOk.
Can we try to pack everything in a PR for Pharo 7.0 ? âThank you.