-
Notifications
You must be signed in to change notification settings - Fork 148
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
Comments
Have you tried 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. |
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. |
@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 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 |
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).
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. |
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. |
An expression that begins with / is now always interpreted as a command. |
Awesome! I'll pull and compile the latest revision! :D Edit: err, compiling failed with complaints about |
Slight issue: when you type |
I should probably close this and open an issue specific to it since this is so old. |
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
andunits
-- 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.
So, it's interpreting
hl
as hectoliters, ande
as euler's identity, from what I can tell. That's... fine, but if I'm trying toguess
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:
/
.Please share your thoughts with me on this! Thanks for listening. ^.^
The text was updated successfully, but these errors were encountered: