This was not the case in C++ if you're using accumulate().

long long int total = accumulate(arr.begin(),arr.end(), 0);

which appears to overflow. I just iterated through the elements in a loop and summed the total instead.

Same here with Ruby. I had to re-read the problem just to make sure that I wasn't reading the same thing.

I tried it in pure C ...a world of pain! But here's the answer

int main(){ int n; long bign = 0; long bignn; scanf("%d",&n); long arr[n]; for(int arr_i = 0; arr_i < n; arr_i++){ scanf("%li",&arr[arr_i]); } for(int arr_i = 0; arr_i < n; arr_i++){ bign = bign + (arr[arr_i]) ; } printf("%ld\n", bign); return 0; }

I'm sure there's some fancy "stuff" you could do in a strongly typed language to determine the type of the result; however, I wonder what the performance implications of that would be versus just starting with type long. Don't know why you got downvoted (I don't write in Python).

Yeah, it seems like the utility of the problem is language dependent. Python 3 doesn't differentiate between int and long types; they're handled exactly the same way from the users perspective.

Yeah but your missing the point. Firstly a number of people are coming here with little to no experience and this is great practice for them.

The problem is clearly labeled as being easy, however maybe that didn't exist 2 years ago when this post was made.

And for people with more experience, it is an opportunity to play around.

Case in point:

def aVeryBigSum(n, ar):
    return reduce(lambda x, y: x + y, ar, 0)

def reduce(func, arr, s):
    for v in arr:
        s = func(s, v)
    return s

super

could you please let me know how you did it? i am trying in bash,no success yet.

That's not industry standard. H4D1 is correct. The way you have it gets really ugly and hard to read, so I would recommend you follow H4D1's recommendation; It could save you a lot of frustration.

Using regular English makes MY life easier. Yet another 'standard' I would like everybody to follow.

It's not "industry" standard: it is language, company, and - sometimes - even product influenced (notice I didn't say determined). The spacing of a language's brackets is entirely preference-based, even if coding conventions are encouraged by documentation (such as MSDN, Oracle, etc.). I've seen some bad stylings in my short time as a programmer.

This is actually worse and should not be an industry standard, this is how you get whats called "spaghetti code" because havign a lot of lines in this fashion will just look to jumbled and harder to debug.

probably you using Python 2 instead of Python 3

This is awesome. Can you hint me where I can read more about operator =>? Googling is not helpful

could you explain what this line is doing please? Thanks

at python3, you net add import as follow: from functools import reduce

print sum(ar)

Solve in C#

using System; using System.Collections.Generic; using System.IO; using System.Linq; class Solution {

static long aVeryBigSum(int n, long[] ar) {
    // Complete this function
    Int64 total = 0;

    for(int i=0; i < n; i++)
    {
        total +=ar[i];
    }
    return total;

}

static void Main(String[] args) {
    int n = Convert.ToInt32(Console.ReadLine());
    string[] ar_temp = Console.ReadLine().Split(' ');
    long[] ar = Array.ConvertAll(ar_temp,Int64.Parse);
    long result = aVeryBigSum(n, ar);
    Console.WriteLine(result);
}

}

You are right. Better to use the "stint" library

Indeed, but I've found in certain challenges the zero needs to be there or the reduce doesn't work properly. I haven't quite wrapped my head around what causes that so I've probably developed a habit of putting it in every time just to be explicit.

Thanks, I only learned about BigInt recently because it is very new. Still not supported by all browsers apparently, but very useful.

Just remove all the existing code in the window and copy paste what is posted above. The existing main function etc make it unnecessarily tougher imo.