### 1. product() unexpected result

- Posted by CraigWelch in April
- 492 views

The math function product() is giving me an unexpected result when the input is an empty sequence.

I test the function as follows:

object void void = {6,6,4,3} ? void void = product(void) ? void puts(1, EOL) void = {6,0,4,3} ? void void = product(void) ? void puts(1, EOL) void = {0,0,0,0} ? void void = product(void) ? void puts(1,EOL) void = {} ? void void = product(void) ? void puts(1, EOL)

This is the result:

{6,6,4,3} 432 {6,0,4,3} 0 {0,0,0,0} 0 {} 1

The last case is giving what is, in my case, a wrong answer.

I can see why the function does this, and understand why the variable b is set to 1 to make the function work. But it's not the result I expect, or want.

I've modified my own version of the routine as follows:

if atom(a) then return a elsif length(a) = 0 then -- CW add return 0 -- CW add end if

Any other thoughts on this ? As always, what is obvious to me might be misguided, I might be missing some bigger picture.

*Craig*

### 2. Re: product() unexpected result

- Posted by ChrisB (moderator) in April
- 477 views

Hi

I agree. The product of a an empty is an empty.

I would be cautious about distributing the code though, as another user might not have the same changes in the library. If you are going to distribute, or come back to the code after an update of Eu, a more cautious approach would be to pre check what you are sending to product().

Cheers

Chris

### 3. Re: product() unexpected result

- Posted by petelomax in April
- 478 views

Can you provide me with a practical example of where product({}) returning 0 would actually be useful? [For me docs]

(you can ignore this now:)

~~See also https://en.wikipedia.org/wiki/Empty_product ~~

~~In a quick search I found that Haskell and Python are quite adamant the answer ~~ *should* be 1.

Update: I've just found a still-commented-out function I wrote in mpfr.e:

function mpz_vecprod(sequence s, object zlr=1) -- -- Fast vector multiplication. -- Multiplying the vector elements in pairs is much faster for essentially -- much the same reason that merge sort is faster than insertion sort. -- Improved rosettacode/Primorial_numbers from 6 minutes to 6 seconds!!!! -- NB: Input sequence s (must all be mpz) is damaged. Returns an mpz. -- Obviously zlr allows you to specify the result when {} is passed, -- since I imagine there'll be cases where you'd rather get a zero, -- and just like mpz_init(), zlr can be an integer, atom, or string. --

**So maybe the answer is for product() to have an optional second parameter, as above defaulting to 1.**

(See https://rosettacode.org/wiki/Primorial_numbers#Phix for the precursor to that, without the zls parameter)

(Note that mpz_vecproc() is/will be obliged to return an mpz, so zlr must be "numeric", but that's not necessarily true for product(), though probably still a good idea?)

### 4. Re: product() unexpected result

- Posted by _tom (admin) in April
- 442 views

/* OE */ include std/math.e ? product( {} ) --> 1

/* p64t Phix */ ? product( {} ) --> 0

## example ''arithmetic'' thinking

Lets say I want to estimate how much redymix concrete I must order:

vol1 = product( { 1,2,3 } ) --> 6 // I order 6 cubic meters of concrete

/* Phix */ vol2 = product( {} ) -- 0 --> zero // no dimensions, I do not order truckloads of concrete

/* OE */ include std/math.e vol3 = product( {} ) -- 1 --> one -- I order a cubic meter of redymix I don't know what do with

## example ''mathematical'' thinking

- x
^{0}= 1 - sqrt( -1 )

= j (electrical thinking)

= i (math thinking) - ...
- product( {} )

= 1

= 0

In ''math'' I am open to various ideas.

## needed

- OE and Phix not the same
- an argument to select mode of operation is needed

be well

_tom

### 5. Re: product() unexpected result

- Posted by petelomax in April
- 432 views

**What?** In phix, product({}) always has and always will return 1.

What *is likely/going* to change is that the previously illegal product({},0) returns 0. Tom, please correct your post.

Anyway, surely product({3,2,1}) returns 6 tons of concrete should be compared against product({0,0,0}) returning 0,

assuming {x,y,z} or {length,width,height|depth} args, but I'll use it anyway (thanks).

I've also just thought of sum({},1) to award a bonus point for "no faults".

### 6. Re: product() unexpected result

- Posted by _tom (admin) in April
- 425 views

yup,

? product( {} )

0

On this side of the pond, everything is backwards?

global function Product(object a) atom res = 0 if atom(a) then res = a elsif length(a) then res = 1 for i=1 to length(a) do res *= product(a[i]) end for end if return res end function ? Product( {} )

0

The concrete example was a bit stretched, but in context of my local city contracts it makes a lot of sense.

''Math'' thinking suits me better.

be well

_tom

### 7. Re: product() unexpected result

- Posted by petelomax in April
- 426 views

Oh, right, it gets messy with that recursion...

I'm going to say that any recursive product/sum calls have to/will simply return 1/0 respectively.

On second thoughts, I'll do it properly: an atom zlr is applied at top level only, but a length 1 sequence is applied recursively.

Here's a link to the freshly updated docs: http://phix.x10.mx/docs/html/sum.htm