Re: [Pharo-dev] summary of "float & fraction equality bug"

Hi, i dont agree with this pov. for example consider this mixed-mode calc: aFraction ln + aNumber. Fraction>>#ln returns a float and i suppose you dont want to change that eg by returning a quasi-NaN like "ResultNonRepresentableInTheSetOfFractionsError". if you suppress (2) and aNumber would be a

Re: [Pharo-dev] feenk log

Hi Doru, you say BLVector is implemented as having instance vars x,y instead of using an Array (like polymath), i guess perhaps because of speed considerations? but i wonder why you then dont use FloatArrays for vectors, their precision, although generally bad, is sufficient for graphics and they

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

On 02/06/2017 09:00 PM, Sven Van Caekenberghe wrote: Regarding the poor seed at startup: 1k outside runs of 'NeoUUIDGenerator new nextRandom16' (on a fresh image) gives me only 116 unique values, compared to the expected 990-1000 In the above it's already second run of the generator, for

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

Hi, i wonder what is the reasoning that "Float nan sign" returns anything else than Float nan? werner On 01/26/2017 09:47 PM, Nicolas Cellier wrote: 2017-01-26 21:22 GMT+01:00 Martin McClure >: Pharo's implementation of Float>>sign

Re: [Pharo-dev] Please test new VMs (round one)

Hi, i downloaded pharo-linux-x86_64itimer.0a4ccdf.zip, pharo-64.zip & PharoV50.sources and simply extracted everything in one folder. i guess this is not the correct procedure? i ask, because, when i print 1.0e19, i get "1.9493552128e10", which looks somehow surprising to me. werner On

Re: [Pharo-dev] roundTo: strange behavior

:. sorry for my confusion. werner On 11/06/2016 01:57 AM, Martin McClure wrote: On 11/05/2016 06:17 AM, werner kassens wrote: Hi, fwiw when i redid that #testIfCompletelyBroken i noticed a sort of bug in that new #round: - well, i think its a feature -, but i should probably mention

Re: [Pharo-dev] roundTo: strange behavior

hence repeatable, stochastic rounding). normal rounding of course introduces an even less wanted upward bias. But perhaps somebody else wants to have a more predictable behaviour of #round:? werner On 11/04/2016 10:26 PM, werner kassens wrote: Hi Stephane, i uploaded a SLICE-Is

Re: [Pharo-dev] roundTo: strange behavior

Hi, i noticed that i have quite some difficulties in producing a slice that makes at least a minimal sort of sense, hence a stupid question: is it ok to make a slice dependent on a preceeding slice? i would guess not, since in the meantime a lot of newer versions of a package in the slice are

Re: [Pharo-dev] roundTo: strange behavior

Hi Stephane, i uploaded a SLICE-Issue-15471-Cant-round-Float-fmax-to-2-decimal-places-WernerKassens.2 to the inbox with these changes: i corrected RandomTest>>testIfCompletelyBroken, completed tests with some border cases and the usual specifications, and added your comment to Float>>round:.

Re: [Pharo-dev] roundTo: strange behavior

Hi Stephan, definitely no. after the test is run, the seed has changed, perhaps you did not reset the seed. ill look into this this night, have to work now, ok? werner On 11/04/2016 03:29 PM, stepharo wrote: Hi guys I loaded the slice 15471 of werner and I run

Re: [Pharo-dev] roundTo: strange behavior

yes Martin, i get that point and i already reacted to it, i occasionally want to calculate something with a rounded float, not print it: apart from my harley i normally use _metric screws which come in decimal steps. let's end that discussion, we are going around in circles. werner On

Re: [Pharo-dev] Missing #removeDuplicates

yes, that _is_ occasionally an advantage. werner On 04/16/2016 03:12 PM, Nicolai Hess wrote: 2016-04-16 14:50 GMT+02:00 Werner Kassens <wkass...@libello.com <mailto:wkass...@libello.com>>: perhaps it is a speed question? using pharo4.0 (with polymath): a:=DhbVector new: 5

Re: [Pharo-dev] Missing #removeDuplicates

perhaps it is a speed question? using pharo4.0 (with polymath): a:=DhbVector new: 50 random: 20. b:=a copy asOrderedCollection . Smalltalk garbageCollect . [ b removeDuplicates]bench. "'47,004 per second'" b:=a copy asArray. Smalltalk garbageCollect . [ b asSet asArray]bench. "'27,249 per

Re: [Pharo-dev] Collections-Arithmetic

look in squeaksource projects for 'Collections Arithmetic extensions' werner On 03/13/2016 01:36 PM, stepharo wrote: Collections extension to treat vectors of number But I cannot find it anymore :) Le 13/3/16 13:30, Sven Van Caekenberghe a écrit : this link does not point to anything for