1. product() unexpected result

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

new topic     » topic index » view message » categorize

2. Re: product() unexpected result

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: product() unexpected result

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?)

new topic     » goto parent     » topic index » view message » categorize

4. Re: product() unexpected result

/* 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

  • x0 = 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

new topic     » goto parent     » topic index » view message » categorize

5. Re: product() unexpected result

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".

new topic     » goto parent     » topic index » view message » categorize

6. Re: product() unexpected result

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

new topic     » goto parent     » topic index » view message » categorize

7. Re: product() unexpected result

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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu