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.

Reply via email to