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

11262015, 03:33 PM
Post: #1




Bug? Odd behavior of [a b/c] with results from mean().
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 

11262015, 04:40 PM
Post: #2




RE: Bug? Odd behavior of [a b/c] with results from mean().
What list are you using?


11262015, 05:43 PM
Post: #3




RE: Bug? Odd behavior of [a b/c] with results from mean().
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. 

11262015, 06:29 PM
(This post was last modified: 11262015 06:35 PM by DrD.)
Post: #4




RE: Bug? Odd behavior of [a b/c] with results from mean().
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 

11272015, 09:52 PM
Post: #5




RE: Bug? Odd behavior of [a b/c] with results from mean().
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. 

11282015, 02:14 PM
(This post was last modified: 11282015 02:22 PM by Joe Horn.)
Post: #6




RE: Bug? Odd behavior of [a b/c] with results from mean().
(11262015 03:33 PM)Michael KK 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 floatingpoint 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 floatingpoint 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. (11262015 03:33 PM)Michael KK 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. <0ɸ0> Joe 

11282015, 06:18 PM
Post: #7




RE: Bug? Odd behavior of [a b/c] with results from mean().
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. 

11282015, 08:00 PM
(This post was last modified: 11282015 08:02 PM by DrD.)
Post: #8




RE: Bug? Odd behavior of [a b/c] with results from mean().
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. 

11292015, 07:29 AM
Post: #9




RE: Bug? Odd behavior of [a b/c] with results from mean().
(11282015 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 (11282015 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...). <0ɸ0> Joe 

11292015, 08:03 AM
Post: #10




RE: Bug? Odd behavior of [a b/c] with results from mean().
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?


11292015, 08:13 AM
Post: #11




RE: Bug? Odd behavior of [a b/c] with results from mean().
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. 

11292015, 09:31 AM
(This post was last modified: 11292015 09:33 AM by Didier Lachieze.)
Post: #12




RE: Bug? Odd behavior of [a b/c] with results from mean().
(11282015 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 It seems that median has been modified after this thread. But the change has not been done for the median value returned by quartiles(). (11292015 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. 

11292015, 11:31 AM
Post: #13




RE: Bug? Odd behavior of [a b/c] with results from mean().
(11292015 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?>> 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). 

« Next Oldest  Next Newest »

User(s) browsing this thread: