Skip to main content
added 4 characters in body
Source Link
Matthieu M.
  • 6.4k
  • 1
  • 21
  • 34

Iteration variable

The most obvious change is that the iteration variable itself doesn't need to be a BigInteger.

A simple int, being a signed 32-bits integer, has an upper limit of 231 - 1, or 2 billions. If takes ~12s to run 1 million iterations, this single int will already be sufficient for over 6 hours.

But if you're really worried, use a long, which as a signed 64-bits integer, will be large enough to run this function until the heat death of the universe.

Or in code:

public readonly IEnumerator<BigInteger> GetEnumerator()
{            
    BigInteger a = 0, b = 1, next;
    for (long i;i = 0; i < n; i++)
    {
        yield return a;
        next = a + b;
        a = b;       
        b = next;                
    }        
}

(You'd need to adapt the constructor to take long n)

This simple change will already reduce one BigInteger operation per iteration, which should speed things up.

Iteration variable

The most obvious change is that the iteration variable itself doesn't need to be a BigInteger.

A simple int, being a signed 32-bits integer, has an upper limit of 231 - 1, or 2 billions. If takes ~12s to run 1 million iterations, this single int will already be sufficient for over 6 hours.

But if you're really worried, use a long, which as a signed 64-bits integer, will be large enough to run this function until the heat death of the universe.

Or in code:

public readonly IEnumerator<BigInteger> GetEnumerator()
{            
    BigInteger a = 0, b = 1, next;
    for (long i; i < n; i++)
    {
        yield return a;
        next = a + b;
        a = b;       
        b = next;                
    }        
}

(You'd need to adapt the constructor to take long n)

This simple change will already reduce one BigInteger operation per iteration, which should speed things up.

Iteration variable

The most obvious change is that the iteration variable itself doesn't need to be a BigInteger.

A simple int, being a signed 32-bits integer, has an upper limit of 231 - 1, or 2 billions. If takes ~12s to run 1 million iterations, this single int will already be sufficient for over 6 hours.

But if you're really worried, use a long, which as a signed 64-bits integer, will be large enough to run this function until the heat death of the universe.

Or in code:

public readonly IEnumerator<BigInteger> GetEnumerator()
{            
    BigInteger a = 0, b = 1, next;
    for (long i = 0; i < n; i++)
    {
        yield return a;
        next = a + b;
        a = b;       
        b = next;                
    }        
}

(You'd need to adapt the constructor to take long n)

This simple change will already reduce one BigInteger operation per iteration, which should speed things up.

Removed mutability, not a problem in C#.
Source Link
Matthieu M.
  • 6.4k
  • 1
  • 21
  • 34

Iteration variable

The most obvious change is that the iteration variable itself doesn't need to be a BigInteger.

A simple int, being a signed 32-bits integer, has an upper limit of 231 - 1, or 2 billions. If takes ~12s to run 1 million iterations, this single int will already be sufficient for over 6 hours.

But if you're really worried, use a long, which as a signed 64-bits integer, will be large enough to run this function until the heat death of the universe.

Or in code:

public readonly IEnumerator<BigInteger> GetEnumerator()
{            
    BigInteger a = 0, b = 1, next;
    for (long i; i < n; i++)
    {
        yield return a;
        next = a + b;
        a = b;       
        b = next;                
    }        
}

(You'd need to adapt the constructor to take long n)

This simple change will already reduce one BigInteger operation per iteration, which should speed things up.

Mutability

I don't usually work with C#, so take this with a grain of salt, however I would have some worry about returning a and keep using it.

If a is returned as is, then the caller could modify the value referred to by a before resuming iteration, messing up the calculation.

For correctness, you may need to return a defensive copy.

Of course, this would come as a cost -- an allocation at each iteration -- but correctness >> performance.

Iteration variable

The most obvious change is that the iteration variable itself doesn't need to be a BigInteger.

A simple int, being a signed 32-bits integer, has an upper limit of 231 - 1, or 2 billions. If takes ~12s to run 1 million iterations, this single int will already be sufficient for over 6 hours.

But if you're really worried, use a long, which as a signed 64-bits integer, will be large enough to run this function until the heat death of the universe.

Or in code:

public readonly IEnumerator<BigInteger> GetEnumerator()
{            
    BigInteger a = 0, b = 1, next;
    for (long i; i < n; i++)
    {
        yield return a;
        next = a + b;
        a = b;       
        b = next;                
    }        
}

(You'd need to adapt the constructor to take long n)

This simple change will already reduce one BigInteger operation per iteration, which should speed things up.

Mutability

I don't usually work with C#, so take this with a grain of salt, however I would have some worry about returning a and keep using it.

If a is returned as is, then the caller could modify the value referred to by a before resuming iteration, messing up the calculation.

For correctness, you may need to return a defensive copy.

Of course, this would come as a cost -- an allocation at each iteration -- but correctness >> performance.

Iteration variable

The most obvious change is that the iteration variable itself doesn't need to be a BigInteger.

A simple int, being a signed 32-bits integer, has an upper limit of 231 - 1, or 2 billions. If takes ~12s to run 1 million iterations, this single int will already be sufficient for over 6 hours.

But if you're really worried, use a long, which as a signed 64-bits integer, will be large enough to run this function until the heat death of the universe.

Or in code:

public readonly IEnumerator<BigInteger> GetEnumerator()
{            
    BigInteger a = 0, b = 1, next;
    for (long i; i < n; i++)
    {
        yield return a;
        next = a + b;
        a = b;       
        b = next;                
    }        
}

(You'd need to adapt the constructor to take long n)

This simple change will already reduce one BigInteger operation per iteration, which should speed things up.

Source Link
Matthieu M.
  • 6.4k
  • 1
  • 21
  • 34

Iteration variable

The most obvious change is that the iteration variable itself doesn't need to be a BigInteger.

A simple int, being a signed 32-bits integer, has an upper limit of 231 - 1, or 2 billions. If takes ~12s to run 1 million iterations, this single int will already be sufficient for over 6 hours.

But if you're really worried, use a long, which as a signed 64-bits integer, will be large enough to run this function until the heat death of the universe.

Or in code:

public readonly IEnumerator<BigInteger> GetEnumerator()
{            
    BigInteger a = 0, b = 1, next;
    for (long i; i < n; i++)
    {
        yield return a;
        next = a + b;
        a = b;       
        b = next;                
    }        
}

(You'd need to adapt the constructor to take long n)

This simple change will already reduce one BigInteger operation per iteration, which should speed things up.

Mutability

I don't usually work with C#, so take this with a grain of salt, however I would have some worry about returning a and keep using it.

If a is returned as is, then the caller could modify the value referred to by a before resuming iteration, messing up the calculation.

For correctness, you may need to return a defensive copy.

Of course, this would come as a cost -- an allocation at each iteration -- but correctness >> performance.