Can the name of the MODE function be changed? (Statistics)

[StephenG1CMZ]

I was trying to look up some way of finding the .mode of a list: Statistically, the most common item(s) in the list.

I found 16 pages of threads about Home mode, CAS mode, Exam mode, and many Interesting threads that I might re-read, but not a single thread about MODE.

Perhaps the HP Prime cannot calculate MODE - or perhaps the absence of any threads about it means everyone else uses it without problems, despite not being in ToolboxMath/Lists.

It would help if the function could be called something's else in the documentation ("statistical-mode" perhaps), to simplify searching.

Similarly, pdf usually refers to document files, not density functions. And while I am complaining, most computer languages use INT to refer to integers, not integration.

(If you are wondering why I don't search the pdf - on Android the phone dims after a couple of pages, and when I restart it, the phone has forgotten that it was searching, which gets VERY tedious).

[rprosperi]

If this question is about the Prime, suggest you request a mod move it to the Prime sub-Forum, you'll get more (and better informed) opinions there.

[StephenG1CMZ]

Making MODE easier to search for in documentation by calling it statistical--mode applies everywhere.

As for not finding it on the Prime, I have now written my own.

[Didier Lachieze]

Here is how I would do a statistical mode function, I don't know how different from yours it is :

Code:

EXPORT ModeList(L)
BEGIN
 LOCAL l1,l2;
 l1:=UNION(L);
 l2:=MAKELIST(SIZE(INTERSECT(L,l1(I))),I,1,SIZE(l1));
 DIFFERENCE(l1*(l2==MAX(l2)),0);
END;

EDITED for a few simplifications.

[StephenG1CMZ]

Wow.

It's amazing what a couple of lines can accomplish when you are familiar with HP Prime built-in functions.

However, I think there is a bug:
{1,2} yields {1,2,0} rather than the expected {1,2}.

Your version doesn't handle {"red","green","red} - but then it is likely much faster as well as more concise.

My own version is mainly written in the style of a C or Pascal program trawling through the lists, with very limited use of built-in functions such as union (thanks for your #21 solution). As such it is likely slower, but perhaps more portable.

It is included in my new list processing API
http://www.hpmuseum.org/forum/thread-9411.html
But I could extract the relevant procedures here if you like.

[Didier Lachieze]

(10-31-2017 11:39 PM)StephenG1CMZ Wrote:  However, I think there is a bug:
{1,2} yields {1,2,0} rather than the expected {1,2}.

Your version doesn't handle {"red","green","red} - but then it is likely much faster as well as more concise.

Ah, I've been too aggressive in the simplifications. Here is an updated version that should work better including for non numeric lists, but it's less concise...

Code:

EXPORT ModeList(L)
BEGIN
 LOCAL l1,l2;
 l1:=UNION(L);
 l2:=MAKELIST(SIZE(INTERSECT(L,l1(I))),I,1,SIZE(l1));
 l2:=(l2==MAX(l2))*MAKELIST(I,I,1,SIZE(l1));
 l2:=remove(0,l2);
 MAKELIST(l1(l2(I)),I,1,SIZE(l2));
END;

[StephenG1CMZ]

As I expected, your implementation is much faster than mine.
About half to two-thirds of my runtime given a list with no duplicates (RANDOM reals), and much faster with duplicates (RANDINT integers).