World: r3wp

Suggest them in CureCode as wishes. Or write them up as mezz or extension 
functions - those are easy to adapt.

will do when I get the chance.

I'm all for it. I've suggested them in the past, but didn't get much 
traction. Here's a non-recursive starting point.

    ; Should our seed value be 0.0 to coerce to decimal? If they
    ; include a decimal value before any overflow, it will be OK.
    ; Changed to match the first type in the block.
    sum: func [block [any-block!] /local result] [
        result: any [
            attempt [make pick block 1 0]
            attempt [0 * pick block 1]
            0
        ]
        foreach value reduce block [result: result + value]
        result
    ]

I just added the wish request.

Why the coersion to decimal?  Just curious.

Should sum [] return 0 or none?

well, if only the default math operators could accept series of scalars 
by default, it would be incredibly simple and powerful.
It should not be so hard to have that behaviour nativly...
A + [1 2 3 4] == A + 1 + 2 + 3 + 4

Vector math has already been suggested.

yep, but we are always waiting

Coercion to decimal would be to prevetn overflow. I prefer not to 
do that though.

Zero versus none is a good question Brian. I have SUM return zero, 
but my AVG func returns none.

0 seems better, it prevents throwing useless errors
(my old claim)

We might not need to coerce to decimal. The first decimal in the 
list will make that coersion for us. And we don't want decimal results 
for a list of integers - it's a loss of precision. I suspect that 
initializing result with the integer 0 will be sufficient.

Then any decimal or money in the list will promote.

Agreed. The only issue is if you don't get a decimal value before 
an overflow occurs, but that's just something to doc.

Actually, documenting that this function doesn't do any error handling 
beyond the arguments of + would be good.

Agreed.

Sounds like the function is moving along.  Great thing is that if 
you build the one you have what you need for the product function 
as well.

sum: func [block [block! vector!] /local result] [
    result: 0
    foreach value reduce block [result: result + :value]
    result
]

Some error handing, some speedups, and vector support.

no need to return the result at the end

foreach do that

Not for a empty block.

right

And it will just throw an error if the block contains anything not 
addable.

That's the R3 way - throw a useful error so the programmer can fix 
their code, no DWIM :)

why the :value?

Your already reducing the block.

In case reducing the block makes a function or some other active 
value - no double eval. It's a way to trip bad errors quicker.

ok.

uggly one-liner version.

sum: func[block [block!]][

 foreach [v1: v2] next head reduce/into block copy [0 0][v1/1: :v2 
 + v1/0]
]
-_-;

yeah !!!! i do not use any locals

...

It uses a lambda local. :-)

i should have used forall, less uggly :-)

And faster. Reversing the order of arguments might not be a good 
idea though - some operators are more forgiving of their left value.

i was not seriously doing a proposal :-)

v1/1: v1/0 + :v2

Yeah, I'm trying to remember (since I didn't comment it) why I coerced 
the result. Something in my brain says there was a good reason.

Maybe I'll remember if we write a test suite for it.

We should make a whole module of math functions, with test code. 
Let the REBOL optimizer at it and then see what we can include.

Who's that optimizer ?

The "REBOL optimizer" is a running joke. The best way to optimize 
your REBOL code is to post it publicly in AltME or R3 chat and dare 
people to improve it. Then the community tries to one-up each other 
to improve it :)

-_-;

It's the best optimizer known to man :)

sure :)

For certain project domains, R3 interpreted code can be faster than 
compiled code, once it's been through the REBOL optimizer.

That happened with some REBOL-vs-Java code the other day here.

but there is several criteria to optimize something.
- Best Speed
- Shortest code
- shortest memory overhead
- best ratio of above criteria

An interesting example of that is AJOIN. The R3 version has less 
memory overhead, the R2 version in 2.7.7 is faster.