Wikifunctions talk:Best practices

New best practice for new best practices

I boldly suggested that the main page should not be added to or amended without first proposing the change here. I am now proposing that this be adopted as a best practice! GrounderUK (talk) 19:36, 10 March 2024 (UTC)

Isn't 'proposal for a best-practice' essentially an essay? Besides, I think it would be odd for a wiki to have a rule saying not to edit a page even to improve it. Arlo Barnes (talk) 00:27, 12 March 2024 (UTC)

I suppose it may be an essay, but I wouldn’t expect it to be. Wikifunctions:Naming conventions is an essay. Are the ideas there put into practice? Should they be? I don’t know, so let’s discuss it (below).

I don’t think it makes sense to talk about Best practices unless there is a community consensus behind them. And if consensus has been achieved, it is appropriate (in my view) to discuss any changes before changing what has been agreed. That is why I propose that it should be considered a Best practice to discuss changes first. But it is just a proposal! GrounderUK (talk) 11:48, 12 March 2024 (UTC)

Could you be clear about how many votes are necessary from others to be considered best practice?

E.g. "3 votes minimum and two weeks of time is enough for considering something best practice and add it to the page" So9q (talk) 07:10, 1 August 2024 (UTC)

I think if there is active support and no dissent, we can call that a consensus. Given consensus, I suggest we propose a final draft on Project Chat and post it to the main page after 48 hours (if there is still no dissent). GrounderUK (talk) 15:45, 11 August 2024 (UTC)

Sounds good to me So9q (talk) 04:07, 13 August 2024 (UTC)

Wikifunctions:Naming conventions

Are these adopted as they stand? GrounderUK (talk) 00:29, 12 March 2024 (UTC)

@GrounderUK: Maybe? I'd suggest a ping on WF:Project chat that this page exists and proposals are being discussed before we make things "official" though? Jdforrester (WMF) (talk) 14:56, 12 March 2024 (UTC)

Yes, it’s on my to-do list. Thanks! GrounderUK (talk) 15:02, 12 March 2024 (UTC) Done

I’ve added a paragraph on characters that might cause difficulties in searches. (phab:T361015.)

There was a clear poll on the capitalisation section here: Wikifunctions:Project_chat/Archive/2023/08 (at the end of that page) --99of9 (talk) 04:37, 8 April 2024 (UTC)

Connecting tests

"If a test is a valid statement about how the function should evaluate, then it should be connected to the function even if no implementation currently passes the test." from Wikifunctions:Project_chat/Archive/2023/12#Questions_around_string_reversal_and_tests --99of9 (talk) 11:00, 12 March 2024 (UTC)

I second this. 😀 So9q (talk) 07:06, 1 August 2024 (UTC)

 Support GrounderUK (talk) 15:46, 11 August 2024 (UTC)

Connecting implementations

"Implementations which have inferior accuracy compared to other connected implementations across the currently connected tests should may be disconnected. For this purpose, timeouts are not necessarily counted as inaccurate." from [1]. --99of9 (talk) 11:06, 12 March 2024 (UTC)

I second this. So9q (talk) 07:07, 1 August 2024 (UTC)

 Support I suggest we amend this to “…may be disconnected…”. Speaking only for myself, I wouldn’t be in any hurry to disconnect an implementation unless it was causing problems (or expected to). In theory, WikiLambda System should always prefer a more accurate implementation. Further, I would encourage a notification on the function’s talk page (rather than the implementation’s). I’m happy to go ahead with the current proposal without modification, however. GrounderUK (talk) 15:59, 11 August 2024 (UTC)

Ok, I've made that tweak. --99of9 (talk) 05:01, 13 August 2024 (UTC)

Support 😀 So9q (talk) 07:12, 14 August 2024 (UTC)

Generalize functions with code as much as possible

Don't: add a new function "swedish noun -s declension" that do exactly the same as "german -s declension" ie add -s to end of a string with a python code implementation in each.

Do: create a new function like add suffix to string if it does not already end with the suffix (Z17973) that takes a string and a suffix and use it in compositions in all the language functions that need it when possible. (Idea by @GrounderUK) So9q (talk) 10:52, 19 July 2024 (UTC)

Hmm. I was always vaguely assuming that those functions would switch from taking a generic string (Z6) to taking a monolingual string (Z11) in whatever language. There'd then be the possibility for a "front-of-house" function to take a Z11 in many languages and match it to the appropriate function on the back-end. Having general low-level functions instead is of course also a possibility. What do people think we should do? Jdforrester (WMF) (talk) 15:49, 19 July 2024 (UTC)

I would think the outer function is language-specific (and this is where we might interact with Wikidata Lexemes, particularly for irregular forms). The innermost functions can be pure string manipulations for regular forms/representations. A “front-of-house” dispatch function would need to know something about the language the input text is in and something about its grammatical features. But whether the result is derived or fetched from a Lexeme should not affect the function’s return type, so I would expect that for outer functions it would generally be Multilingual text (Z12) or Monolingual text (Z11) (where the required form is specific enough). Another structure to consider, though, is a single string with an array of “languages”, for cases where a representation is common to many language variants. Similarly, when different forms or lexemes have the same representations, a single representation (or set of representations) and an array of lexeme form types. GrounderUK (talk) 19:46, 19 July 2024 (UTC)

This doesn't play well with agressive caching.

What happens if a lexeme is wrong causing multiple functions in that language to return an incorrect output, then somebody fix the lexeme but the cache is never invalidated?

@Jdforrester (WMF) are there plans to invalidate or removal caching for functions which rely on outside data from Wikidata? So9q (talk) 07:17, 14 August 2024 (UTC)

@So9q: Yes, there are plans. :-) Jdforrester (WMF) (talk) 16:52, 19 August 2024 (UTC)

SI units should be used by default

Distance between two points on Earth (SI-unit output in meters) (Haversine formula) (Z14446) output both km and miles in a string.

I would much prefer it to use a single SI unit. Another function can be used to convert the result to miles, km or other units for users who want that.

I think this should be a best practice.

"In functions we prefer single results in SI units. E.g. implementations should use meters over miles for distance calculations and include SI-unit in the label. Likewise all temperature related functions should output Kelvin. Other functions can then concert kelvin to degrees or other scales."

According to NIST these are the basic SI-units:

   Second – Unit of Time. Symbol: s.
   Meter – Unit of Length. Symbol: m.
   Kilogram – Unit of Mass. Symbol: kg.
   Ampere – Unit of Electric Current. Symbol: A.
   Kelvin – Unit of Thermodynamic Temperature. Symbol: K.
   Mole – Unit of Amount of Substance. Symbol: mol.
   Candela – Unit of Luminous Intensity. Symbol: cd.

See wikipedia:International_System_of_Units-- So9q (talk) 07:25, 1 August 2024 (UTC)

I encourage submission of Type proposals for different units and systems of units. In fact, I created a link for SI units months ago. I’m inclined to suppose that we shall have different Types for each of the basic units but it might make sense to have a single proposal covering all those units. Until we get concrete proposals, I would say that there should be a single implicit unit per function. I don’t think it matters what the unit is, so long as it’s clear; thus we can convert between degrees on the Celsius and Fahrenheit scales without reference to kelvin, for example. GrounderUK (talk) 16:11, 11 August 2024 (UTC)

Sounds good to me. 😀 So9q (talk) 08:59, 12 August 2024 (UTC)

Comma format?

We use string input to do calculations currently. Because of that we need to agree on which comma format to use in all these functions until we have a float number type. I propose we use '.' So9q (talk) 08:25, 1 August 2024 (UTC)

@So9q: Do you mean radix and thousands values? Those should be interpreted from (user input, user language) into the standard form by the type parser function, your functions that use them shouldn't have to worry? Jdforrester (WMF) (talk) 20:39, 29 August 2024 (UTC)

I think So9q is talking about functions which (temporarily) return their floating point output as a string. Such as (!) sine (Z16463). I agree that using a decimal point as a decimal marker makes sense for consistency (and ease of output from implementations). But I don't care that much, because I don't personally plan to work on these functions until the real floating point type is available. 99of9 (talk) 00:13, 30 August 2024 (UTC)

Exactly. So9q (talk) 05:53, 30 August 2024 (UTC)

Well, abusing supported Types as stand-ins for not-yet-supported Types isn't something I think we can have "best practices" around, other than "please do not do this"… Jdforrester (WMF) (talk) 13:58, 9 September 2024 (UTC)