Large integers, ** and Int

--000feaf25ebfab7ff1048d6c220a
Content-Type: text/plain; charset=UTF-8

I've been running into all sorts of problems trying to take S02 at its word
that Int supports arbitrary precision. It *sort of* does. But there are the
edge cases where it doesn't. This might just be something that's not there
yet, and I understand, but I thought I should report it.

If exponentiation (**) exceeds some pre-set limit, the result will be a Num.

 ok((10**100) ~~ Int, "Googol is of type Int"); # Fails
 ok((10.Int ** 100.Int) ~~ Int, "Googol is of type Int (cast)"); # Fails

The .Int method on an overly large integer literal will yield spurious
results if it's larger than the native type can store (but note that this
might be platform-specific):

 ok((1000000000000000000).Int > 0, "10^18 > 0"); # Passes
 ok((10000000000000000000).Int > 0, "10^19 > 0"); # Fails

The S02 is also very unclear on what the types of the various numeric
literals are. It would be really helpful if it made that really clear (not a
p6-compiler issue, I know).

When this happens, non-intuitive things can happen, type-wise:

$ ./perl6 -e 'my Int $x = 10000000000000000000'
[works fine]
$ ./perl6 -e 'my Int $x = 10000000000000000000 + 1'
Type check failed for assignment
  in '&infix:<=>' at line 1
  in main program body at line 1

--000feaf25ebfab7ff1048d6c220a--
0
ajs
8/9/2010 11:11:24 PM
perl.perl6.compiler 1237 articles. 0 followers. Follow

12 Replies
922 Views

Similar Articles

[PageSpeed] 10

Am 10.08.2010 01:11, schrieb Aaron Sherman:
> I've been running into all sorts of problems trying to take S02 at its word
> that Int supports arbitrary precision. It *sort of* does.

It does in Perl 6, but not in Rakudo (known limitation).

Moritz
0
moritz
8/10/2010 2:39:30 PM
--001636025e550ff153048d818c50
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 10, 2010 at 10:39 AM, Moritz Lenz <moritz@faui2k3.org> wrote:

> Am 10.08.2010 01:11, schrieb Aaron Sherman:
>
>  I've been running into all sorts of problems trying to take S02 at its
>> word
>> that Int supports arbitrary precision. It *sort of* does.
>>
>
> It does in Perl 6, but not in Rakudo (known limitation).
>
>
Is this an interim limitation, or something that's intended as a long-term
implementation for Rakudo? Parrot does provide a BigInt now, but in trying
to use it, I discovered that it has some really strange limitations (then
again, I don't know PIR very well, so perhaps it was my fault?) For example
I don't seem to be able to invoke modulus on a PMC that holds a BigInt.

But assuming that Parrot's BigInt will be expanded to suit general purpose
needs, is it Rakudo's plan to use it for Int implementation?

-- 
Aaron Sherman
Email or GTalk: ajs@ajs.com
http://www.ajs.com/~ajs

--001636025e550ff153048d818c50--
0
ajs
8/11/2010 12:44:06 AM
On Tue, Aug 10, 2010 at 08:44:06PM -0400, Aaron Sherman wrote:
> On Tue, Aug 10, 2010 at 10:39 AM, Moritz Lenz <moritz@faui2k3.org> wrote:
> > Am 10.08.2010 01:11, schrieb Aaron Sherman:
> >  I've been running into all sorts of problems trying to take S02 at its
> >> word that Int supports arbitrary precision. It *sort of* does.
> >
> > It does in Perl 6, but not in Rakudo (known limitation).
> >
> >
> Is this an interim limitation, or something that's intended as a long-term
> implementation for Rakudo? 

It's an interim limitation, but I don't know how long it will be
before Rakudo fixes it.  Certainly Perl 5 has survived for a very long
time without needing its integers to be arbitrary precision by default.


> [...]
> But assuming that Parrot's BigInt will be expanded to suit general purpose
> needs, is it Rakudo's plan to use it for Int implementation?

My guess is that Rakudo will ultimately develop its own 
arbitrary-precision integer representation, rather than trying to use 
the BigInt that comes with Parrot.  Also, IIRC, Parrot's BigInt
implementation only works on systems that have certain libraries
installed.

Pm
0
pmichaud
8/11/2010 4:50:47 PM
--0015174c344a8d0760048d97286e
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 11, 2010 at 12:50 PM, Patrick R. Michaud <pmichaud@pobox.com>wrote:

> On Tue, Aug 10, 2010 at 08:44:06PM -0400, Aaron Sherman wrote:
>


> > Is this an interim limitation, or something that's intended as a
> long-term
> > implementation for Rakudo?
>
> It's an interim limitation, but I don't know how long it will be
> before Rakudo fixes it.  Certainly Perl 5 has survived for a very long
> time without needing its integers to be arbitrary precision by default.
>

Perl 5 and 6 are radically different systems in this respect. Perl 5 deals
with large numbers by storing everything in a double (well... most
everything, there are IVs to be sure, but the user almost always interacts
in NVs when they're doing math). In Perl 6 this doesn't work nearly so well
because it has a typing system which makes automatic conversions painful.
For example, here's an implementation of modpow, much like Perl 5's
Math::BigInt::bmodpow:

 sub modpow(Int $n is copy, Int $exponent, Int $mod) {
        my Int $total = 1;
        for $exponent, * +> 1 ... 1 -> $e {
                $total = ($total * $n) % $mod if $e +& 1;
                $n = ($n*$n) % $mod;
        }
        return $total;
 }


Now, if you pass 10, 10 and 7 to that function, it works fine and you get 4.
But if you pass larger values:

modpow(100000, 100000, 7)
Type check failed for assignment
  in '&infix:<=>' at line 1
  in 'modpow' at line 9:./modp.p6
  in main program body at line 19:./modp.p6

You just can't silently upgrade a type to an incompatible type on the fly
like that without expecting any code with type constraints to break. It
would almost be better to raise an overflow exception. At least then, the
programmer could catch it and deal with it appropriately.



> > [...]
> > But assuming that Parrot's BigInt will be expanded to suit general
> purpose
> > needs, is it Rakudo's plan to use it for Int implementation?
>
> My guess is that Rakudo will ultimately develop its own
> arbitrary-precision integer representation, rather than trying to use
> the BigInt that comes with Parrot.  Also, IIRC, Parrot's BigInt
> implementation only works on systems that have certain libraries
> installed.
>

Well... that's true, but unlike some libraries out there, gmp isn't exactly
a difficult dependency to meet. To quote their site:

GMP's main target platforms are Unix-type systems, such as GNU/Linux,
Solaris, HP-UX, Mac OS X/Darwin, BSD, AIX, etc. It also is known to work on
Windows in both 32-bit and 64-bit mode.

And this from the GCC 4.3 release notes:

GCC requires the GMP and MPFR libraries for building all the various
front-end languages it supports.

I think Perl 6 would be doing amazingly well if it *only* ran everywhere
that all of gcc 4.3's front-end languages ran... Not to mention the fact
that GMP is amazingly fast. What would you write Perl 6's implementation in
that could come near the hardware-optimized performance of GMP? The thing
ships with hand-optimized assembly (including things like MMX/SSE support)
across dozens of processor platforms. I know we put a lot of faith into the
magical day when Perl 6 is jitted down into its optimal machine code, but I
don't think it's rational to expect to be able to touch GMP's performance,
and most applications that care about arbitrarily large integers actually do
care about performance.

-- 
Aaron Sherman
Email or GTalk: ajs@ajs.com
http://www.ajs.com/~ajs

--0015174c344a8d0760048d97286e--
0
ajs
8/12/2010 2:31:06 AM
On Wed, Aug 11, 2010 at 10:31:06PM -0400, Aaron Sherman wrote:
>     My guess is that Rakudo will ultimately develop its own
>     arbitrary-precision integer representation, rather than trying to u=
se
>     the BigInt that comes with Parrot. =A0Also, IIRC, Parrot's BigInt
>     implementation only works on systems that have certain libraries
>     installed.
>=20
> Well... that's true, but unlike some libraries out there, gmp isn't exa=
ctly a
> difficult dependency to meet. [...]

I wasn't intending to imply that we would not be using the gmp library;
only that Parrot's current interface, build system, and implementation is=
n't=20
the way we're likely to do it.

I'm not saying "don't use Parrot bignums" for this.  I'm saying that bign=
um=20
support isn't a high priority for the core at the moment, that when we=20
do implement bignums it probably won't use the Parrot-supplied BigInts (b=
ecause
of other core changes in the pipeline), and that we'd likely entertain
patches if someone wanted to try to get Rakudo to work with Parrot's bign=
ums
(but they'll likely get massively refactored with the new object system).

Pm
0
pmichaud
8/12/2010 4:43:03 PM
Patrick R. Michaud wrote:
> On Wed, Aug 11, 2010 at 10:31:06PM -0400, Aaron Sherman wrote:
>>     My guess is that Rakudo will ultimately develop its own
>>     arbitrary-precision integer representation, rather than trying to use
>>     the BigInt that comes with Parrot.  Also, IIRC, Parrot's BigInt
>>     implementation only works on systems that have certain libraries
>>     installed.
>>
>> Well... that's true, but unlike some libraries out there, gmp isn't exactly a
>> difficult dependency to meet. [...]
> 
> I wasn't intending to imply that we would not be using the gmp library;
> only that Parrot's current interface, build system, and implementation isn't 
> the way we're likely to do it.
> 
> I'm not saying "don't use Parrot bignums" for this.  I'm saying that bignum 
> support isn't a high priority for the core at the moment, that when we 
> do implement bignums it probably won't use the Parrot-supplied BigInts (because
> of other core changes in the pipeline), and that we'd likely entertain
> patches if someone wanted to try to get Rakudo to work with Parrot's bignums
> (but they'll likely get massively refactored with the new object system).

What is the difference between Parrot bignums and gmp?  Could Parrot not just 
use gmp to implement its bignums? --  Darren Duncan
0
darren
8/12/2010 7:48:45 PM
--0015174c16ac07df1f048db5dba4
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 12, 2010 at 3:48 PM, Darren Duncan <darren@darrenduncan.net>wrote:

>
> What is the difference between Parrot bignums and gmp?  Could Parrot not
> just use gmp to implement its bignums? --  Darren Duncan
>

Parrot does use GMP. What we're discussing is how appropriate those are for
Perl 6. My feeling is that the closer Perl 6 can get to using GMP directly,
the better. If we need to wrap Parrot BigInt in a Perl 6 class, that
wouldn't be terrible.

I've been trying to get that to work myself, but I've been struggling with
getting a PIR BigInt into a Perl 6 attribute via Q:PIR. When I do this:

                        .local pmc value, attr
                        .local pmc b
                        value = find_lex "$value"
                        b = new ['BigInt']
                        b = value
                        attr = find_lex "$field"
                        attr = b

Where $field is the variable I want to store, $field.WHAT is Int(). Is that
what I should expect, or has my value been silently converted?


-- 
Aaron Sherman
Email or GTalk: ajs@ajs.com
http://www.ajs.com/~ajs

--0015174c16ac07df1f048db5dba4--
0
ajs
8/13/2010 3:08:30 PM
On Fri, Aug 13, 2010 at 11:08:30AM -0400, Aaron Sherman wrote:
> On Thu, Aug 12, 2010 at 3:48 PM, Darren Duncan <darren@darrenduncan.net>wrote:
> 
> >
> > What is the difference between Parrot bignums and gmp?  Could Parrot not
> > just use gmp to implement its bignums? --  Darren Duncan
> >
> 
> Parrot does use GMP. What we're discussing is how appropriate those are for
> Perl 6. My feeling is that the closer Perl 6 can get to using GMP directly,
> the better. If we need to wrap Parrot BigInt in a Perl 6 class, that
> wouldn't be terrible.

It ultimately needs to be wrapped into a Perl 6 Int -- there's not a
separate "big integer" type.  

Or, put another way, we need Rakudo's Int class to be smart enough to 
adapt to using a bigint representation (e.g., Parrot's BigInt PMC)
whenever the values are outside of a native int.

Pm

> I've been trying to get that to work myself, but I've been struggling with
> getting a PIR BigInt into a Perl 6 attribute via Q:PIR. When I do this:
> 
>                         .local pmc value, attr
>                         .local pmc b
>                         value = find_lex "$value"
>                         b = new ['BigInt']
>                         b = value
>                         attr = find_lex "$field"
>                         attr = b
> 
> Where $field is the variable I want to store, $field.WHAT is Int(). 

Note that .WHAT won't typically work on Parrot native values,
unless they've somehow been registered into the P6object framework.

Pm
0
pmichaud
8/14/2010 12:56:37 PM
--0015174c435a71ecd9048ddfcde7
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 14, 2010 at 8:56 AM, Patrick R. Michaud <pmichaud@pobox.com>wrote:

> On Fri, Aug 13, 2010 at 11:08:30AM -0400, Aaron Sherman wrote:
> > On Thu, Aug 12, 2010 at 3:48 PM, Darren Duncan <darren@darrenduncan.net
> >wrote:
> >
> > >
> > > What is the difference between Parrot bignums and gmp?  Could Parrot
> not
> > > just use gmp to implement its bignums? --  Darren Duncan
> > >
> >
> > Parrot does use GMP. What we're discussing is how appropriate those are
> for
> > Perl 6. My feeling is that the closer Perl 6 can get to using GMP
> directly,
> > the better. If we need to wrap Parrot BigInt in a Perl 6 class, that
> > wouldn't be terrible.
>
> It ultimately needs to be wrapped into a Perl 6 Int -- there's not a
> separate "big integer" type.
>

That shouldn't be the case unless you're going to implement everything in
Int that you can do with a GMP-based bigint or at least support
auto-promotion if you try to do a GMP-only function on an Int. For example,
GMP provides low-level implementations of primality testing, GCD, modular
exponentiation, returning and modifying bit indexes in single operations
(e.g. "set bit 121 to 0") without having to create a new bigint mask value.

I would think that Int would encapsulate a BigInt which it would use as
needed, but also expose to the user for advanced functionality, e.g.:

 my Int $a = 10**100;
 my $b = $a.bigint;
 $b.setbit(150);
 say $b.nextprime;


> Or, put another way, we need Rakudo's Int class to be smart enough to
> adapt to using a bigint representation (e.g., Parrot's BigInt PMC)
> whenever the values are outside of a native int.
>

Handling large integers is only the start of what modern multi-precision
integers are there for. Really, what they're becoming is high performance
math libraries, sans the typical arbitrary limitations of native ints. Not
providing that to Perl 6 users seems a wasted opportunity.

-- 
Aaron Sherman
Email or GTalk: ajs@ajs.com
http://www.ajs.com/~ajs

--0015174c435a71ecd9048ddfcde7--
0
ajs
8/15/2010 5:11:10 PM
Patrick R. Michaud wrote:
> On Fri, Aug 13, 2010 at 11:08:30AM -0400, Aaron Sherman wrote:
>> On Thu, Aug 12, 2010 at 3:48 PM, Darren Duncan <darren@darrenduncan.net>wrote:
>>
>>> What is the difference between Parrot bignums and gmp?  Could Parrot not
>>> just use gmp to implement its bignums? --  Darren Duncan
>>>
>> Parrot does use GMP. What we're discussing is how appropriate those are for
>> Perl 6. My feeling is that the closer Perl 6 can get to using GMP directly,
>> the better. If we need to wrap Parrot BigInt in a Perl 6 class, that
>> wouldn't be terrible.
> 
> It ultimately needs to be wrapped into a Perl 6 Int -- there's not a
> separate "big integer" type.  
> 
> Or, put another way, we need Rakudo's Int class to be smart enough to 
> adapt to using a bigint representation (e.g., Parrot's BigInt PMC)
> whenever the values are outside of a native int.

I think it would make sense for Parrot to provide the abstraction directly as to 
whether a bigint or a native int was being used, so Rakudo and other language 
implementations that just want to have a single all-purpose integer type can use 
it rather than having to have their own promotion or abstraction logic.

I seem to recall a discussion on this happening a year ago, although that might 
have been with respect to Perl 5.

-- Darren Duncan
0
darren
8/16/2010 12:18:38 AM
--0015174be884b4c0a2048e0cc377
Content-Type: text/plain; charset=UTF-8

Re-sending my message which went to parrot-dev, and should have gone to
perl6-compiler. Sorry.

On Tue, Aug 17, 2010 at 6:48 PM, Aaron Sherman <ajs@ajs.com> wrote:

>
> On Tue, Aug 17, 2010 at 11:51 AM, Moritz Lenz <moritz@faui2k3.org> wrote:
>
>> Aaron Sherman wrote:
>> > I did eventually discover that I needed to do this. The problem then
>> > became that I can't reliably get exporting an infix:<+> operator from a
>> > module to work.
>>
>> When you try, make sure to declare it as 'our', since Rakudo doesn't
>> fully handle lexical exports yet.
>>
>> # probably also needs type constraints
>> our multi sub infix:<+>($a, $b) is export {
>>    # your code here
>> }
>>
>
> This is what my signature looks like right now (I've re-named my module
> BigTest just to avoid confusion while I develop):
>
>  our multi sub infix:<+>(BigTest $lhs, BigTest $rhs) is export {
>         return BigTest.new(:value(Q:PIR {
>           ...
>         };
> }
>
> When I "use" that file, and try to add:
>
> ./perl6 -e 'use BigTest; my BigTest $i .=
> new(:value("1000000000000000000000000")); $i = $i + $i; say $i'
>
> I get:
>
> Type check failed for assignment
>   in '&infix:<=>' at line 1
>   in main program body at line 1
>
> If I comment out the Numeric method in my class, then that error changes
> to:
>
> Can't take numeric value for object of type BigTest
>   in 'Any::Numeric' at line 1339:CORE.setting
>   in 'infix:<+>' at line 6752:CORE.setting
>   in main program body at line 1
>
> So it looks like it's just totally unwilling to try to use that inline:<+>
> that I've defined, and instead is dead-set on trying to convert my BigTest
> to a Numeric in order to match an alternate signature.
>
> --
> Aaron Sherman
> Email or GTalk: ajs@ajs.com
> http://www.ajs.com/~ajs
>

--0015174be884b4c0a2048e0cc377--
0
ajs
8/17/2010 10:49:40 PM
On Tue, Aug 17, 2010 at 6:49 PM, Aaron Sherman <ajs@ajs.com> wrote:
> On Tue, Aug 17, 2010 at 6:48 PM, Aaron Sherman <ajs@ajs.com> wrote:
>> On Tue, Aug 17, 2010 at 11:51 AM, Moritz Lenz <moritz@faui2k3.org> wrote=
:
>>
>>> Aaron Sherman wrote:
>>> > I did eventually discover that I needed to do this. The problem then
>>> > became that I can't reliably get exporting an infix:<+> operator from=
 a
>>> > module to work.
>>>
>>> When you try, make sure to declare it as 'our', since Rakudo doesn't
>>> fully handle lexical exports yet.
>>>
>>> # probably also needs type constraints
>>> our multi sub infix:<+>($a, $b) is export {
>>> =A0 =A0# your code here
>>> }
>>>
>>
>> This is what my signature looks like right now (I've re-named my module
>> BigTest just to avoid confusion while I develop):
>>
>> =A0our multi sub infix:<+>(BigTest $lhs, BigTest $rhs) is export {
>> =A0 =A0 =A0 =A0 return BigTest.new(:value(Q:PIR {
>> =A0 =A0 =A0 =A0 =A0 ...
>> =A0 =A0 =A0 =A0 };
>> }
>>
>> When I "use" that file, and try to add:
>>
>> ./perl6 -e 'use BigTest; my BigTest $i .=3D
>> new(:value("1000000000000000000000000")); $i =3D $i + $i; say $i'
>>
>> I get:
>>
>> Type check failed for assignment
>> =A0 in '&infix:<=3D>' at line 1
>> =A0 in main program body at line 1
>>
>> If I comment out the Numeric method in my class, then that error changes
>> to:
>>
>> Can't take numeric value for object of type BigTest
>> =A0 in 'Any::Numeric' at line 1339:CORE.setting
>> =A0 in 'infix:<+>' at line 6752:CORE.setting
>> =A0 in main program body at line 1
>>
>> So it looks like it's just totally unwilling to try to use that inline:<=
+>
>> that I've defined, and instead is dead-set on trying to convert my BigTe=
st
>> to a Numeric in order to match an alternate signature.

I believe this is probably something funky about using -e.  At least,
from the REPL:

> use Math::Vector
_block98
> my $a =3D Math::Vector.new(0.0, 1.0, 2.0);
(0, 1, 2)
> say $a + $a
Can't take numeric value for object of type Math::Vector

but the following script:

use Math::Vector;
my $a =3D Math::Vector.new(0.0, 1.0, 2.0);
say $a + $a;

works fine, generating (0, 2, 4) as its output.

--=20
Solomon Foster: colomon@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com
0
colomon
8/18/2010 2:45:36 AM
Reply:

Similar Artilces:

[perl6/specs] 5cad81: Int % Int should give Int, not Rat.
----==_mimepart_53947fd3be929_3581d6bd34320aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 5cad8110c936c392b8a4304781ef767e1a7d7b0c https://github.com/perl6/specs/commit/5cad8110c936c392b8a4304781ef767e1a7d7b0c Author: Konrad Borowski <x.fix@o2.pl> Date: 2014-06-08 (Sun, 08 Jun 2014) Changed paths: M S03-operators.pod Log Message: ----------- Int % Int should give Int, not Rat. ----==_mimepart_53947fd3be929_3581d6bd34320aa-- ...

[perl6/specs] 740854: actually mention that % does (Int, Int) -> Int
----==_mimepart_539571c07840c_45e9f4bd34603aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 740854ee4da1568dac9dd2deef8bfa0d95d839ef https://github.com/perl6/specs/commit/740854ee4da1568dac9dd2deef8bfa0d95d839ef Author: Carl Masak <cmasak@gmail.com> Date: 2014-06-09 (Mon, 09 Jun 2014) Changed paths: M S03-operators.pod Log Message: ----------- actually mention that % does (Int, Int) -> Int ----==_mimepart_539571c07840c_45e9f4bd346...

perl6-compiler
perl6-compiler is missing at http://dev.perl.org/perl6/lists/ and it seems not to be gatewayed to nntp.perl.org. OTOH a lot of unused perl6 lists and newsgroups are there. Finally I tried to subscribe already twice and got no answer. Thanks, leo http://www.nntp.perl.org/group/perl.perl6.compiler -- It's there. Correct, though, that it's not listed on the lists page... On Thu, 21 Oct 2004 09:02:23 +0200, Leopold Toetsch <lt@toetsch.at> wrote: > perl6-compiler is missing at http://dev.perl.org/perl6/lists/ and it > seems not to be gatewayed to nntp.perl...

compile too large!
When I save a nuo_object , the complier alwayse pay caution : script is too large,so I want how to modify the content of complier in pb ! Thanks a lot! Hi, Couldn't you parse your object code into a few userevents/functions? Under normal conditions, it should be more easy to maintain (and use) it. Do you have a large choose/case? Did you think about inheriting and then 'create using' syntax? The effect is as the XBase's 'DO &PROC' God luck!. "forums.sybase.com" <ldscyrti@hotmail.com> escribi� en el mensaje news:gPwbWKTBBHA.28...

perl6 compiler
Hello, I had just began looking at the perl6 raduko compiler and have a question. Is perl6 actually compiled then ran similar to java or is the script ran and then compiled at run time? -Wendell On Mar 14, 2010, at 11:09 AM, dell wrote: > Is perl6 actually compiled then ran similar to java > or is the script ran and then compiled at run time? It supports either, but defaults to single-step compile-run (like Perl 5). I think that a transparent cache is envisioned for the future, so that a compiled version is silently saved during the first compil...

to compile or not to compile ?
Hi I've been dabbling with  .net but am now trying to bite the bullet and learn it moving from classic asp I am a bit confused as to wether it is 'standard' practise to 'build' your project into dll's and upload these to the server or wether to simply use script and upload as you would classic asp to the server. what is 'standard' practise is there an advantage or disadvantage to using script / compiling thanks What is "Standard" depends a bit upon the tool you are using. For VS.NET 2003, compiling into a dll placed in the bin folder is the default behavior.  Othe...

[perl6/specs] b50c8a: Change Int() notation to (Int) notation
----==_mimepart_5129187d24090_50f91a50af491229 Date: Sat, 23 Feb 2013 11:29:01 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <5129187d252d5_50f91a50af4913e@sh2.rs.github.com.mail> Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: b50c8aa4785cb11875deb3008fe8216c33e481b1 https://github.com/perl6/specs/commit/b50c8aa4785cb11875deb3008fe8216c33e481b1 Author: Larry Wall <larry@wall.org> Date: 2013-02-23 (Sat, 23 Feb 2013) Changed paths: M S12-objects.pod ...

DXE3 compiler super slow/crash at compiling/running large projects
Just recently purchased Delphi XE3 Professional Named license ESD in order to port our application from D6 but there seems to be a serious problem with the IDE and compiler, large projects seem to be an issue since our application would compile and run in D6 IDE in under 5 seconds while in DXE3 the time surpasses one minute which is highly ineffective and time consuming. Just to be rule out computer problems I've installed the license on another computer that I use and it's the same sluggish run time. The IDE becomes unresponsive while compiling/debugging and takes 50% of CPU, al...

superreview requested: [Bug 406251] int value conversion problem in NPRuntime, doesn't work with large ints ( high bits set)
Johnny Stenback (:jst) <jst@mozilla.org> has asked Peter Van der Beken <peterv@propagandism.org> for superreview: Bug 406251: int value conversion problem in NPRuntime, doesn't work with large ints (high bits set) https://bugzilla.mozilla.org/show_bug.cgi?id=406251 Attachment 290942: Don't mess up with large ints. https://bugzilla.mozilla.org/attachment.cgi?id=290942&action=edit ------- Additional Comments from Johnny Stenback (:jst) <jst@mozilla.org> This makes us use JS_NewNumberValue() instead of assuming INT_TO_JSVAL will do the right thing with a...

superreview granted: [Bug 406251] int value conversion problem in NPRuntime , doesn't work with large ints (high bits set)
Peter Van der Beken <peterv@propagandism.org> has granted Johnny Stenback (:jst) <jst@mozilla.org>'s request for superreview: Bug 406251: int value conversion problem in NPRuntime, doesn't work with large ints (high bits set) https://bugzilla.mozilla.org/show_bug.cgi?id=406251 Attachment 290942: Don't mess up with large ints. https://bugzilla.mozilla.org/attachment.cgi?id=290942&action=edit ...

superreview granted: [Bug 218832] [W] UMR: Uninitialized memory read in nsView::ConvertToParentCoords(int *,int *)const : [Attachment 131204] Fix UMR and stop treating the pointers like integers, do
Robert O'Callahan <roc@ocallahan.org> has granted timeless@myrealbox.com <timeless@bemail.org>'s request for superreview: Bug 218832: [W] UMR: Uninitialized memory read in nsView::ConvertToParentCoords(int *,int *)const http://bugzilla.mozilla.org/show_bug.cgi?id=218832 Attachment 131204: Fix UMR and stop treating the pointers like integers, don't lose input http://bugzilla.mozilla.org/attachment.cgi?id=131204&action=edit ...

superreview cancelled: [Bug 218832] [W] UMR: Uninitialized memory read in nsView::ConvertToParentCoords(int *,int *)const : [Attachment 131180] Fix UMR and stop treating the pointers like integers
timeless@myrealbox.com <timeless@bemail.org> has cancelled timeless@myrealbox.com <timeless@bemail.org>'s request for superreview: Bug 218832: [W] UMR: Uninitialized memory read in nsView::ConvertToParentCoords(int *,int *)const http://bugzilla.mozilla.org/show_bug.cgi?id=218832 Attachment 131180: Fix UMR and stop treating the pointers like integers http://bugzilla.mozilla.org/attachment.cgi?id=131180&action=edit ...

superreview requested: [Bug 218832] [W] UMR: Uninitialized memory read in nsView::ConvertToParentCoords(int *,int *)const : [Attachment 131180] Fix UMR and stop treating the pointers like integers
timeless@myrealbox.com <timeless@bemail.org> has asked Robert O'Callahan <roc@ocallahan.org> for superreview: Bug 218832: [W] UMR: Uninitialized memory read in nsView::ConvertToParentCoords(int *,int *)const http://bugzilla.mozilla.org/show_bug.cgi?id=218832 Attachment 131180: Fix UMR and stop treating the pointers like integers http://bugzilla.mozilla.org/attachment.cgi?id=131180&action=edit ...

superreview requested: [Bug 218832] [W] UMR: Uninitialized memory read in nsView::ConvertToParentCoords(int *,int *)const : [Attachment 131204] Fix UMR and stop treating the pointers like integers,
timeless@myrealbox.com <timeless@bemail.org> has asked Robert O'Callahan <roc@ocallahan.org> for superreview: Bug 218832: [W] UMR: Uninitialized memory read in nsView::ConvertToParentCoords(int *,int *)const http://bugzilla.mozilla.org/show_bug.cgi?id=218832 Attachment 131204: Fix UMR and stop treating the pointers like integers, don't lose input http://bugzilla.mozilla.org/attachment.cgi?id=131204&action=edit ...

Web resources about - Large integers, ** and Int - perl.perl6.compiler

On-Line Encyclopedia of Integer Sequences - Wikipedia, the free encyclopedia
The On-Line Encyclopedia of Integer Sequences ( OEIS ), also cited simply as Sloane's , is an online database of integer sequences , created ...

Interactive Integers - Addition and Subtraction on the App Store on iTunes
Get Interactive Integers - Addition and Subtraction on the App Store. See screenshots and ratings, and read customer reviews.

Starbucks Taps Omnicom's Integer For Efforts Outside Its Stores
Omnicom Group's Integer Group has been added to the Starbucks roster after the coffee giant sought an agency for a big shopper-marketing push. ...

The New C: Integers in C99, Part 1 - Dr Dobb's December 2000/The New C
C has its roots in typeless languages, but it has come a long long way from its humble beginnings.

New MIT Debugger Checks for Integer Overflows
MIT's Directed Integer Overflow Detection (DIODE) debugger automatically finds integer overflows, which can potentially allow hacker attacks. ...

Gamasutra: Max Woolf's Blog - Diablo III Economy Broken by an Integer Overflow Bug
The following blog was, unless otherwise noted, independently written by a member of Gamasutra's game development community. The thoughts and ...

AWS EC2 C3/C4 Multicore Integer Performance Comparison
The C4 family, on average, had a 14 percent increase in integer performance over the C3 family. The c4.8xlarge VMs exhibited the largest performance ...


View Count for PSY’s ‘Gangnam Style’ Music Video Surpasses the 32-Bit Integer Max Value on YouTube
YouTube has upgraded their view count tracking after the music video for “Gangnam Style” by PSY surpassed the 32-bit integer max positive value ...

The saddest thing I know about integers
This is for math geeks and musicians. What really happens if you use a circle of fourths or fifths to tune an instrument?

Resources last updated: 12/1/2015 3:03:56 AM