Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

General problem with 'intelligent guessing' attempts #115

Closed
crabdancing opened this issue Oct 27, 2018 · 9 comments
Closed

General problem with 'intelligent guessing' attempts #115

crabdancing opened this issue Oct 27, 2018 · 9 comments

Comments

@crabdancing
Copy link

I really love what this project is doing, and its feature set is awesome, but I ultimately ended up moving to using other simpler and more specific projects like wcalc and units -- and I've come back to think about why exactly that is.

The unit conversion feature of libqalculate is awesome, but the way it is so eager to make guesses about what the user meant, creates chaos -- at least, in my use case. For instance, here's what happens if I misspell the help command.

hlep

So, it's interpreting hl as hectoliters, and e as euler's identity, from what I can tell. That's... fine, but if I'm trying to guess a unit name, and end up wrong, it will break it down into gibberish. Furthermore, if I'm trying to get it to solve an equation, often if the variable names happen to match units it will erroneously try to process them as such -- it tries to be very intelligent and guess what the user means in ambiguous situations.

I'd like to know if it would be possible to build some sort of 'non-guessy' mode for this app, which uses something more like a formal language so that the user's intent is more explicit -- but still including all the same functionality. The difference here is something like the difference between Wolfram Alpha and Mathematica, I suppose, but it doesn't have to be nearly as formalized and explicit as Mathematica. I'm just wondering about a happy medium of some sort.

As some examples, I imagine a more explicit mode would:

  1. Identify commands using an escape character, e.g. IRC's /.
  2. require units to be separated by spaces -- any blob of unrecognized text is a single unit -- not interpretable as like 5 units for some accidental nonsensical dimensional analysis.
  3. Have some ability to clearly distinguish between units and variables -- perhaps by adding a symbol like $ before the variables, a la Bash.

Please share your thoughts with me on this! Thanks for listening. ^.^

@hanna-kn
Copy link
Contributor

Have you tried set limit implicit multiplication on (and possibly set parsing mode conventional, and occasionally set units off)? Also, qalculate-gtk (although I understand that you might prefer the CLI) allows you to see the parsed expression as you type and makes it easier to switch between modes.

I agree that an alternative mode along the lines of your suggestions might be beneficial. The default mode should however still strive to allow the user to enter expressions as they appear in ordinary texts (it is still far from perfect in this respect), without the need to read a manual.

@vvs-
Copy link

vvs- commented Oct 28, 2018

IMHO, Qalculate! has too many options already and it can only get worse. The problem lays in ever increasing complexity and that UI is trying to be jack of all trades. I doubt that such universal interface or language could exist. There are metamodes in GTK UI but it's still limited by the same set of options.

From the other hand many languages can coexist for the same core library. Some other calculators offer different personalities, and for the most demanding there could be a formal domain specific language where any assumed context should be declared explicitly. But that might be even different project. What I'd like to see is a higher level of abstraction to support such tasks, so that future users wouldn't need to study general purpose programming language or internal implementation details.

My two cents.

@crabdancing
Copy link
Author

crabdancing commented Oct 30, 2018

@vvs- Yeah, that does sound like it'd meet my and many other use cases with minimal duplication of effort... I wonder if a completely reworked fork would be in order, and then once it was ready, just attach the CLI as a frontend to that, and write other frontends for different use-cases that make use of the same backend code. But that might be too idealistic of me.

@hanna-kn No I haven't, as I wasn't able to find those options upon skimming the docs... but turning off implicit multiplication would help my use case. Although it's really not ideal because I'm fine with implicit multiplication -- it should just require a space between the units to permit it.

And as for units, is there some way to turn units on but only for the duration of a single line, e.g., a command starting with convert or maybe conv for short?

Otherwise, switching it on and off would be pretty hectic. The whole reason I opened this issue was because I was getting pretty sick of switching between wcalc and units in tmux when they performed functions that could be rolled into one -- and switching the option on and off sounds more workflow-taxing that hitting `0 and `1 to toggle between tmux windows.

@hanna-kn
Copy link
Contributor

hanna-kn commented Oct 30, 2018

Although it's really not ideal because I'm fine with implicit multiplication -- it should just require a space between the units to permit it.

This would require yet another option, which might not be a good idea (I'm definitely not going to change the default since common unit expressions such as kWh would then not be allowed). Calculation or "hlep" might be unattractive, but it should be obvious what went wrong and it should not affect efficiency much. Can you provide some other examples where it becomes more of a problem.

If it is primarily the conflict with unknown variables (with unknowns enabled) that is problematic, then quotation marks can be used for these (5'a''b'^2 will not be interpreted as 5 attobarn²). It might be a good idea to complement the quotation marks with an alternative notation (not 5$b$a^2 since it conflicts with dollars, but perhaps 5\a\b^2) and then intelligently remove the additional characters in the result.

I've grouped options in qalc which hopefully should make the many alternatives a bit more manageable. In addition I do believe that a few preset meta modes (changing a appropriate subsets of options) might be beneficial in qalc. A pure algebra mode would perhaps enable exact mode, fractions and unknowns (which should be displayed without quotation marks), and disable units (although some variables such as the speed of light, 'c', might also be problematic).

And as for units, is there some way to turn units on but only for the duration of a single line, e.g., a command starting with convert or maybe conv for short?

The "units off" mode can definitely be smarter. I've now changed the behaviour so that units are always enabled when the expressions ends with "to [unit expression]", "to optimal" or similar.

@hanna-kn
Copy link
Contributor

hanna-kn commented Oct 30, 2018

I've now made changes so that a character can be preceded by \ to mark it as an unknown variable (same as in quotation marks), and undefined unknown variables will be italicized instead of put in quotation marks in the result (in qalc; qalculate-gtk did this before). Example: (6\a\b^2) / (2\b) = 3 ab.

@hanna-kn
Copy link
Contributor

hanna-kn commented Oct 30, 2018

An expression that begins with / is now always interpreted as a command.

@crabdancing
Copy link
Author

crabdancing commented Oct 30, 2018

Awesome! I'll pull and compile the latest revision! :D

Edit: err, compiling failed with complaints about config.h as seen here.

@crabdancing
Copy link
Author

Slight issue: when you type base without any args, it tells you about the usage -- but when you type /base without any args, it responds with Unknown command.

@crabdancing
Copy link
Author

I should probably close this and open an issue specific to it since this is so old.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants