On 16 April 2010 05:30, Ralph Versteegen <[email protected]> wrote: > On 16 April 2010 04:40, Mike Caron <[email protected]> wrote: >> I really hope that 53-bit is a key-shift typo of 64-bit, because 53-bit >> anythings would be insane! >> >> NOTE: does not apply for bases that are multiples of 53 >> >> -- >> Mike Caron > > 64 bit doubles have a 52 bit significand plus one implied bit, meaning > they can encode integers up to 2^53-1
Well, of course they'll be able to encode 2^53 exactly as well. >> -----Original Message----- >> From: James Paige <[email protected]> >> Date: Thu, 15 Apr 2010 08:46:05 >> To: <[email protected]> >> Subject: Re: [Ohrrpgce] SVN: teeemcee/3504 HSpeak: Fixed a large number of >> bugs in the constant expression optimise >> >> On Thu, Apr 15, 2010 at 06:25:00PM +1200, Ralph Versteegen wrote: >>> On 15 April 2010 05:49, James Paige <[email protected]> wrote: >>> > On Wed, Apr 14, 2010 at 10:18:08AM -0700, [email protected] >>> > wrote: >>> >> teeemcee >>> >> 2010-04-14 10:18:08 -0700 (Wed, 14 Apr 2010) >>> >> 375 >>> >> HSpeak: Fixed a large number of bugs in the constant expression >>> >> optimiser, including: -1 was used as truth instead of 1; negative >>> >> division rounded in wrong direction; lots of different ways to crash >>> >> HSpeak such as division by zero; was using 31 bit instead of 32 bit >>> >> integers. >>> >> >>> >> Also added optimisation for new math operators, and ability to optimise >>> >> overflowing expressions. >>> > >>> > Awesome! I remember 32 bit integers being difficult in Euphoria, 31 bit >>> > being the only supported int type at the time. Has it gotten any easier >>> > in the latest euphoria? >>> >>> It's the same as it's always been, and actually pretty simple. You >>> just use atoms as 53-bit integers, and define an int32 type. >> >> 53-bit integers? Huh? I don't remember euphoria supporting any more than >> 31 bit, be they atoms or otherwise. Maybe I just didn't know about it? >> Or maybe that didn't exist back in the Euphoria 2.1 days? >> >>> > What sort of optimization do new math operators do now? >>> >>> I added not, logand, logor, logxor. logand and logor are deleted if >>> their first argument is 0 or 1 respectively. >>> >>> There are more optimisations that could be done such as if(not(A)) >>> then(B) else(C) => if(A) then(C) else(B). Originally I was worried >>> about transformations like that being confusing when trying to debug >>> scripts, but the stepping features of the script debugger are >>> effectively scrapped, and error line number reporting won't be >>> confused, so I'll proceed. >> >> Ah, that is nifty. >> >> --- >> James >> _______________________________________________ >> Ohrrpgce mailing list >> [email protected] >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> _______________________________________________ >> Ohrrpgce mailing list >> [email protected] >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
