Bug? Odd behavior of [a b/c] with results from mean().

[Michael K-K]

Hi,

I don't know if this has been reported earlier.
When calculating the mean of a list and you would expect a floating point number, the prime gives a fraction which can't be converted to decimal with the [a b/c]-button. The really funny thing is, this works fine with median().

Can anyone confirm this?

[Firmware 8151]

Greetings,
Michael

[DrD]

What list are you using?

[Michael K-K]

First I used build in L1. Then a list {} directly put on stack.
I further recognized this:

1) mean({1, 2, 3, 4}) -> 5/2
2) mean({1.0, 2.0, 3.0, 4.0}) -> 5/2
3) mean({1, 2, 3, 4, 2.5}) -> 2.5

1) + 2) the [a b/c] does nothing, 3) [a b/c] works as expected. No problem with median and [a b/c] in all three cases.

[DrD]

TYPE() median and mean: 0=real vs. 8=function (in HOME view)
type() median and mean: DOM_FLOAT, DOM_FLOAT (in CAS view)

[a b/c] works as expected in CAS view

[retoa]

Same problem in RPN mode, and there you can't do anything useful with the result.

Shift Enter does not work and if you take the fraction from the stack you can not use it because 3/2 is not in RPN syntax.

[Joe Horn]

(11-26-2015 03:33 PM)Michael K-K Wrote:  When calculating the mean of a list and you would expect a floating point number, the prime gives a fraction which can't be converted to decimal with the [a b/c]-button.

Not a bug. mean() is a CAS function designed to return exact symbolic results, e.g. mean({x,y,z,t}) returns '(x+y+z+t)/4' in CAS. If you want to call it from Home and have it always return approximate floating point results, go to CAS Setup and uncheck the "Change apparent integers into exact integers" option (1st page, 3rd line, right end). To have the same effect in CAS, uncheck the "Exact" option in CAS Settings (5th line). These settings control whether or not CAS functions return exact results or floating-point results in Home and CAS respectively. It's nice to be able to change this behavior as needed.

Also, please note that the fraction key [a b/c] in Home does not change actual symbolic fractions (like '2/3', note the single quotes) into reals. Try it; in Home, type '2/3', press Enter then [a b/c] and see that it doesn't do anything. Or calculate exact(1.5) in Home and try pressing [a b/c] on the result. On the other hand, when you type 1.5 in Home, press Enter, and then press [a b/c], that's not REALLY a symbolic fraction you see; it's merely a helpful but fictional display mode, sorta like FIX 2. The real floating-point number (at full accuracy) is still there on the history stack, hidden behind the fictional fraction that's being displayed. This is radically different from the behavior of the [a b/c] key in CAS, where it is simply a shortcut for calling the exact() or approx() functions.

(11-26-2015 03:33 PM)Michael K-K Wrote:  The really funny thing is, this works fine with median().

That's because median() never returns a fraction. When given an even number of items, it returns the one before the middle, not the average of the middle two items.

[Helge Gabert]

Good explanation, except median does result in the average of both middle terms, if the list has an even number of objects, at least in the current firmware

median({4,7,8,14}) returns 7.5 in CAS.

[DrD]

A list containing an even amount of numbers, after placing the numbers in increasing order, the median is half the sum (the average) of the two middle numbers.

If the list contains an odd amount of numbers, the median is the middle number, of the numerically ordered list.

[Joe Horn]

(11-28-2015 06:18 PM)Helge Gabert Wrote:  Good explanation, except median does result in the average of both middle terms, if the list has an even number of objects, at least in the current firmware

median({4,7,8,14}) returns 7.5 in CAS.

(11-28-2015 08:00 PM)DrD Wrote:  A list containing an even amount of numbers, after placing the numbers in increasing order, the median is half the sum (the average) of the two middle numbers.

Then median's behavior is inconsistent, because in CAS, when a, b, c, and d are nonexistent variables, median({a,b,c,d}) returns b, not (b+c)/2. (At least at this moment on this Prime emulator with its current settings on this laptop...).

[DrD]

Are we left to assume the alphabetical order is the weights? How would median know where to find the center of a list of variable elements?

[Michael K-K]

Thank you all for your replies!
@Joe Horn: The setting in CAS did it, now mean() is doing in HOME as expected.

The problem with median() is weird. I tried in CAS (hardware Prime)
median({a,b,c,d}) -> b
median({a,c,b,d}) -> b

In HOME it is working fine.

[Didier Lachieze]

(11-28-2015 06:18 PM)Helge Gabert Wrote:  Good explanation, except median does result in the average of both middle terms, if the list has an even number of objects, at least in the current firmware

median({4,7,8,14}) returns 7.5 in CAS.

It seems that median has been modified after this thread.
But the change has not been done for the median value returned by quartiles().

(11-29-2015 08:03 AM)DrD Wrote:  Are we left to assume the alphabetical order is the weights? How would median know where to find the center of a list of variable elements?

Median works on ordered sequences so if you have a list of undefined variables the alphabetical order seems quite logical.

[DrD]

(11-29-2015 08:03 AM)DrD Wrote:  <<Are we left to assume the alphabetical order is the weights? How would median know where to find the center of a list of variable elements?>>


Median works on ordered sequences so if you have a list of undefined variables the alphabetical order seems quite logical.

I understand, but paradoxically to me, the notion of "ordered sequences," "of undefined variables," is sort of like trying to find the median of mass chaos without any boundaries. (Perhaps resolved by the optional second list, containing weights for the first list, as described in the help topic).