1. product() unexpected result
- Posted by CraigWelch Apr 29, 2021
- 1185 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) Apr 29, 2021
- 1150 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 Apr 29, 2021
- 1188 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) Apr 29, 2021
- 1139 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
- 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
5. Re: product() unexpected result
- Posted by petelomax Apr 29, 2021
- 1133 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) Apr 29, 2021
- 1121 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 Apr 29, 2021
- 1125 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