True, that meaning seems to be typical now. The opposite is the original meaning though.
> Scores of authors use the phrase “steep learning curve” or “sharp learning curve” in reference to a skill that is difficult to master. . . . Nevertheless, from the standpoint of learning theory, these and other authors have it backward, because a steep learning curve, i.e., a curve with a large positive slope, is associated with a skill that is acquired easily and rapidly (Hopper et al., 2007).
Everyone is talking about curves, but no one's talking about how the axes are labeled.
Based on common usage of the term learning curve, I had thought of it much like a power curve where the y-axis is the amount of cumulative effort you have to put in to reach a particular point on the x-axis, which measures mastery. Sounds like the official definition is effort on the x-axis and the total amount you've learned on the y-axis, which would indeed invert the meaning from how I've understood it.
While writing this, I mostly focused on what I like about Restic's design that Duplicati doesn't have, but they're both great. Duplicati is definitely easier to use for anyone not familiar with command line tools. Feedback is welcome!
Banks are for-profit and credit unions are not-for-profit. Banks will do whatever they think they can get away with to increase their profits, which affects every interaction you have with them. I've had accounts at Citibank and now multiple credit unions, and I regret ever having had accounts at Citibank. They were constantly making things difficult in new ways. I don't know how the bureaucracy compares, but how they treat customers is definitely different.
Location: Los Angeles, CA
Remote: open to remote, in-person, and hybrid
Willing to relocate: yes
Technologies: Python, C++, JavaScript, C, Go, C#, Java, SQL, HTML/CSS, Git, Linux
Résumé/CV: chriswheeler.dev/resume.pdf
Email: email@chriswheeler.dev
You might not get a notification when you get into the beta. That's what happened to me and someone else who told me about it. Check the DuckDuckGo app every once in a while to see if you're in.
SpeedCrunch looks very promising, and I've used it a lot in the past. I'm sad to see that they still haven't released the order of operations bug fix [0] they made in 2017.
SpeedCrunch does some operations in an order most people wouldn't expect. For example, SpeedCrunch says 1/2(-9.8) = -0.05102040816326530612
You could make 1/2x where x = 4 evaluate to either 2 or 0.125, but either choice will have surprising results in some cases or to some people. Perhaps a better choice, especially for an interactive calculator, is to adopt partially ordered operator precedence, and reject the expression as ambiguous. Then the user can insert parentheses to disambiguate.
In a CFG this is easy enough to express. Here's an untested and at any rate incomplete CFG demonstrating the technique:
expr ::= term | term "+" expr | term "-" expr
term ::= quotient | product
quotient ::= atom "/" atom | atom "/" quotient
product ::= atom product | atom "*" product | atom
atom ::= number | variable | "-" atom | "(" expr ")"
But typical parser generators don't give you an easy way to provide a useful error message there.
That version of the grammar, btw, avoids left recursion, so it ought to work as a PEG, but at the cost of the wrong associativity for "/" and "-". You either need to use left recursion or restructure the syntax tree afterwards.
> You could make 1/2x where x = 4 evaluate to either 2 or 0.125
Ouch, you just made me think that if I see this equation just "horizontally" like it's presented here, I would say 2. But if I imagine it like you would write it on paper, I would answer 0.125.
That is a thing you can do, and for example units(1) does just that, but doing it creates the usability problems we are discussing in its thread. My comment is aimed at solving those problems, not worsening them.
The disconnect is that a lot of people mentally treat implicit multiplication with a higher priority than explicit, which is pretty understandable. For instance:
1/3x
is likely to be understood as 1/(3*x), because otherwise it would’ve been written like x/3. If that’s true, then so surely
1/3(x)
should be the same, right?
Smarter people than I have argued both sides of this, and I don’t have a strong opinion except to use parentheses if there’s any possible ambiguity. Just saying, I totally understand why you’d come to that conclusion, and I probably would too.
The part that confuses me is why someone would think the SpeedCrunch implementation is correct:
Say again that you have 1/3x. This is implicitly stating 1/3x. However, no parenthesis are used, and multiplication & division are on the same level in the order of operations, so the expression gets evaluated sequentially from left to right.
If you have 1/3(9.8), evaluating the parenthesis gives you 9.8. So you now have 1/39.8. The expression inside the parenthesis gets evaluated first, then the final result is just multiplied by whatever precedes or succeeds the parenthetical if no other term is given. So 1/3+(9.8) would obviously evaluate to be 1/3+9.8.
Again, if the parenthesis aren't enclosing operations within themselves, then they shouldn't modify the way you'd evaluate the expression. I've had this problem with SpeedCrunch many times over and wish they would update it. Still the best desktop calculator IMO.
Implied multiplication (with no operator) has a higher precedence than explicit multiplication (with an operator). Most mathematicians see it this way.
Really though, order of operations is just a convention. Practically, I'd think of PEMDAS as descriptive rather than proscriptive (nobody is going to revoke your math license if you and your friends violate PEMDAS together). Frequent topics of debate or confusion seem to indicate a edge case in the living convention. Therefore, I think you are smarter than either of the debaters if you stick with the parentheses.
I would be confused if 1/2gt^2 would mean anything but 1/2 g t^2 and 0.5 g t^2. 1/3x in isolation may look a bit unusual, but with context the choice between 1/3 x and x / 3 may actually convey additional information, information about the structure of the calculation. Manipulating an equation into some kind of normal form may lose information.
Yes, that answer is incorrect since it breaks with calculator conventions. The contents of the parentheses are calculated first (P in PEMDAS), and then the multiplication is done later (MD in PEMDAS). Implicit multiplication (which does not explicitly use a multiplication sign) has the same priority as any other multiplication:
a/b(c) = a/b*c = (a/b)*c
Since SpeedCrunch only accepts input in a single line, this would be the least unexpected way to interpret the expression, and consistent with how graphing calculators operate.
A horizontal fraction bar, which SpeedCrunch does not support (since it only accepts single-line input), implies parentheses around the numerator and denominator. For example:
ax
-- = (ax)/(by) = (a*x)/(b*y)
by
compared to
ax/by = a*x/b*y = ((a*x)/b)*y
(If the above is not displayed correctly, please view this comment on the HN website.)
Implicit multiplication is a point of frequent confusion:
To guarantee that the expression does not get misinterpreted, the person writing the expression should always add parentheses/brackets and explicit multiplication signs, or use horizontal division bars where possible, to make the expression unambiguous.
Not even calculators agree on this. Here's a picture of my Casio fx-83ES and fx-83GT calculators giving different answers to "8/2(2+2)": https://i.imgur.com/SsKUQrE.jpg
Both answers are completely, 100% correct according to the operator precedence table in their manuals. I also have a Casio fx-83MS and fx-991ES, both give 1 as the answer.
Others I have are a Casio fx-570CD and a Casio statistical calculator I don't remember the model of, neither of which support implicit multiplication, and a SwissMicros DM42, which is RPN and doesn't have to deal with operator precedence.
Looking at this issue and then trying Qalculate! as some of the other commenters to this post have mentioned.... I tried 1/2(-9.8) and it calculated it as -0.05102040816 as I was doing the entry. As soon as I hit enter, however, it popped open a dialog box saying "The expression is ambiguous" and asked me to select an interpretation of expressions with implicit multiplication, setting a preference for later use. The choices were:
That's the perfect way to deal with this case. I've been using Qalculate! for quite some time, but never saw this dialog because I've apparently never entered an ambiguous expression before. Thanks for sharing this.
I have to say, it's really disappointing to see similar models from the same brand act differently. Thanks for testing this out and shedding more light on this issue.
You're right. The division sign is also unambigious. Unfortunately, it's not usually found on keyboards so many people are accustomed to using slashes.
SpeedCrunch and other calculator apps still need to have an unambiguous way of interpreting the expression when the user types or pastes in a slash. The apps could convert slashes to division signs before displaying them on the screen, since that's how the symbols should be interpreted. This is how GNOME Calculator resolves the ambiguity.
It’s a question of whether the above is supposed to mean (1/2)(-9.8), or 1/(2(-9.8)). Technically it’s ambiguous (I think), in practice it’s obviously the former, because if it was the latter you’d write it as 1/(2-9.8).
> Scores of authors use the phrase “steep learning curve” or “sharp learning curve” in reference to a skill that is difficult to master. . . . Nevertheless, from the standpoint of learning theory, these and other authors have it backward, because a steep learning curve, i.e., a curve with a large positive slope, is associated with a skill that is acquired easily and rapidly (Hopper et al., 2007).
Source: Fifty psychological and psychiatric terms to avoid: a list of inaccurate, misleading, misused, ambiguous, and logically confused words and phrases (https://www.frontiersin.org/journals/psychology/articles/10....)
reply