wendelstein7 / discordunitcorrector Goto Github PK

Description

While extremely large numbers (like the mass of the sun), are output in metric using scientific notation, inputs are not recognized as scientific notation and instead must be directly entered as a decimal.

This shows the method by which an input must be given in order to elicit a conversion. However, since no right-minded person would text the mass of the sun over Discord in such a way, we should expect never to make such a conversion. Instead, we should expect to find scientific notation.

Example Failure Cases

• The form A.BCeD
  
• The form A.BCe+D
  
• The form A.BC*10^D
  
• The form A.BC*!0^+D
  

Other similar forms exist and can (and perhaps should) be supported.

Proposed Solutions

• Expand the regex for finding numbers, and add any addition "pythonizing" between the string catching and float conversion (current "pythonizing" consists of a forced conversion from the comma to the period as radix)
• Import a library for parsing numbers from strings

Potential Related Issues

• No idea what sort of licensing requirements or such would come with adding a library

Description

Three relatively significant errors exist in the definitions of the non-SI units that the bot will correct, when used. Specifically...

• While square inches, square feet, and square miles are units of area (Source), they are declared as units of distance.
• Capital Cal or Calories should represent the food calorie (equivalent to the kilocalorie or 1000 calories). Lowercase cal or calories should represent the physical calorie (equivalent to the calorie or 0.001 kilocalories). The bot treats both capitalizations as lowercase.
• A "ton of refrigeration" is not a unit of energy, but instead of unit of power (Source - see page 67 or page 73. This source is cited on Wikipedia, and reading this relevant article will give the same information).

Example Failure Cases

• Square feet, inches, and miles:
  
  
  
• Capitalization of calories:
  
  
  
  
• Tons of refrigeration:
  

Proposed Fixes

• Change the values supplied to the unitType parameter so that square inches, square feet, square miles, and tons of refrigeration are represented with correct units in the output.
• Migrate the calories and kilocalories unit to a new Unit subclass that allows case insensitivity (potentially moving some code to adhere to DRY without making classes backwards-incompatible), then update the matching regex for each unit.

Potential Related Issues

• Changes in the Unit class structure may result in backwards incompatibility of the API. However, if this is deemed an unavoidable, necessary evil, it may be a good opportunity to reevaluate the flexibility of the rest of the existing class structure. That said, I think it is most likely that any changes used to solve this issue will leave us with a backwards-compatible version of the class structure, and that this will not be an issue.

Description

Some units that are relatively common or easy to implement can help contribute to the completeness of the bot and infrequency with which it misses conversions. I propose adding the cubic inch and cubic foot for a commonality that contributes to the infrequency with which conversions are missed, and I propose adding square and cubic versions of all distance units (where they are not yet implemented). I also propose adding the Reamur, Rommer, Newton, and Delisle temperature sytems.

Example Failure Cases

• Check for degrees reamur
  
• Check for deg De
  
• Check for smoot^3
  
• Check for inch^3
  

Proposed Fixes

• Explicitly add each unit to the list of units in the bot's registry.
• Where needed, explicitly add units to the registry. For area and volume units that are powers of distance units, use a loop to iterate over each distance unit and insert it subsequent to the already-registered area units and distance units.

Potential Related Issues

• Some of the units related to those in this expansion are currently misdefined, see #25.
• Automated unit generation could create collision between unit label strings or unit label strings that are common in non-measurement speech. However, because square units and cube units must be explicit about a higher dimension, I don't think that the second proposed fix should actually cause this issue.

Description

When receiving a message such as
string 1 pound
, the bot will correctly correct it. However, the space between string and 1 will be omitted as follows:
string454 g.

Fixes

I assume that this is a result of bad regex somewhere.
The cheap, scuffed fix would be to just add a space.
Another fix that depends on the user is to use 2 spaces.
Nonetheless, it is an inconvenience.

Description

One thing that a lot of our imperial unit mebers dislike is the sass the bot has, rather than simply translating the unit into metric. It kind of does it in an unpleasant way with a sassy tone. I understand the bot is made to tease imperials but is there a way to turn off the sassy tone and rather simply get the unit conversion?

quoted from CuriousGeorge on Discord

This issue is being created because there is no way to turn off the sassy tone, but there could be.

Proposed Fixes

• Add a role to the bot, to individual users, or to both that determines whether or not the bot will use the default, sassy tone or a polite tone. Details: Role precedence, role names.
  • Possible role precedence: user role takes precedence over bot role, any existing role takes precedence over any nonexistent role, and if no roles are found, default behavior is used.
  • Possible role names: bot role is named "polite" and user role is named "politeconversions" OR both roles are named the same of "polite" or "politeconversions" OR both roles have different names with similar essences.
  • Rationale: extremely simple for users and not overcomplicated for development, albeit with an expense of minor server cluttering, and provides relatively simple potential for future expansion
• Change a nickname to determine the tone. Details: how the nickname is changed, whose nickname is changed.
  • Possible nickname changes: add an instructional word like "polite" or "sassy" in its entirety to the niickname, add a symbol like | or * or ^ to the nickname
  • Whose nickname: the bot OR the user OR both.
  • Rationale: extremely simple for users and not overcomplicated for development, and eliminates the server clutter used to control the bot at the expense of having control strings appear in conversations
• Require channels to be present to control behavior. Details: channel nature and format.
  • Possible channel natures and formats: create a (possibly empty) category channel with a name that tells the bot if it should behave politely OR create a (possibly empty) text channel with a name that tells the bot if it should behave politely OR create a voice channel with a name that tells the bot if it should behave politely OR create a non-empty text channel containing all the control information for the bot from which the bot can read its instructed tone choice OR create a category channel containing empty text channels from which
  • Rationale: changes the type of server clutter, which allows some servers to better bury this additional clutter among their existing disorganization, and provides relatively simple potential for future expansion
• Store preferences sent to the bot via a message command. Details: storage format, storage location
  • Possible storage format: store an ordered list of setting strings, store a list of labelled settings strings (as in a hashmap), store a list of octets that choose settings from enumerations by each of their values
  • Possible storage location: online third-party database,
  • Rationale: creates no additional clutter and great potential for future expansion while being relatively user-friendly, but forces the bot to cease to be stateless, creating significant development complications
    Although it would further complicate development and maintenance, support for more than one of the possible fixes listed above, at the same time, would give users even greater control over how the bot behaves and looks in their servers.

Potential Related Issues

• Bot reply latency could be significantly increased by the need to read settings (especially in a stateless manner), and bot resource load could also suffer.
• Conflict with other bot-control structures in servers to which we deploy could occur with stateless settings.
• Legal issues are related to a bot with a non-stateless design (solvable issues, but issues nonetheless).

Description

When the bot corrects a user in a server, the user is referred to by their user tag, not by their nickname. Given that it is more likely that a user is called by their nickname than their real name, the bot should also call users by that name.

Example failure case

Proposed Fixes

• Change message.author.name to message.author.display_name in

  DiscordUnitCorrector/unitbot.py

  Line 43 in 8d57433

  correctionText = ("I think " + (message.author.name if message.guild is not None else "you") + " meant to say: ```" + processedMessage + "```")

MPH converts to meters per second (m/s) instead of KPH
It makes more sense to convert to KPH instead of m/s

Currently, message I am 1 inch 3 feet. corrects to I am 2.54 cm 0.914 m..

Rather, it would be favourable if it'd result in one combined SI unit: I am 0.93 m.

Different input prompts may find different amount of significant digits relevant. A measurement of whole feet typically doesn't need up to three significant digits. While 3 feet gets corrected to 0.914 m, perhaps 0.9 m or 0.91 m would suffice.

Perhaps the significance of the input could be taken into account: prompt 3.00 feet or 12.54 stone would result in more significant digits than 3 feet and 12 stone would.

1 US Liquid Pint = 0.832674 Imperial Pints

Imperial is stupid.

Can unitcorrector provide both types of pints when it detects someone talking about pints? In Britain, pubs serve drinks in Imperial pints, not US pints.