The numbers in that csv from is in float, but with the fraction part is 0. This is most likely caused by the fact that the precision for timing is in milliseconds, not microseconds. Even the #primUTCMicrosecondsClock only updates per millisecond for me. (Windows).
((1 to: 100000) collect: [:n | Time primUTCMicrosecondsClock ] as: Set) asArray sort. “for me each entry is increased by 1000” Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Aliaksei Syrel Sent: Saturday, March 12, 2016 9:01 PM To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: Re: [Pharo-dev] Comparison of actual and expected Delay length on small durations I get a BoxedFloat64(61.5) Very strange... For some unexpected reason you get integers in delay test. But all values should be floats. I double checked the script.. There is a difference in arithmetic behaviour between mac and windows! Cheers, Alex On Sat, Mar 12, 2016 at 8:48 PM, Cyril Ferlicot D. <cyril.ferli...@gmail.com<mailto:cyril.ferli...@gmail.com>> wrote: Le 12/03/2016 20:44, Aliaksei Syrel a écrit : > I think we just found a serious bug! > > Cyrill, could you perform a division in the same image you used for > delay test and post result here? > > 123 / 2.0 > I get a BoxedFloat64(61.5) -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
