@EmilioPisanty It is indeed a terrific syntax improvement... but named Function arguments still have scope problems. I've stuck to slot notation ever since a particularly unpleasant debugging session found this:
g[fn_] := {1} /. {b_} :> fn[b]
f[x_] := a |-> a + x
g[f[10]]
(* 11 *)
f[x_] := b |-> b + x (* uh-oh, "b" is used in "g" *)
g[f[10]]
(* error: Parameter specification 1 in Function[1,10+1] should be a symbol or a list of symbols. *)
As someone who writes a lot of higher-order functions, the new syntax appears very sweet. But, for me at least, the scoping problem makes it too bitter :)
Given that I have a function $f$ with respect to $n$ variables $\lambda_1, \cdots, \lambda_n$. Namely,
$$
f(\lambda_1, \cdots, \lambda_n) \quad 0 < \lambda_i < 1
$$
Now I investigate one of its special cases, i.e., all the $\lambda_i$ is set to the same value.
$$
\bar f(\lambda) \quad 0 < \la...
@Nat The problem is that this is just Wolfram Alpha's interpretation. As far as Mathematica is concerned, degC is just an algebraic symbol like x. The real difficulty is that the ideal gas law requires temperatures in K and therefore T degC is a short-hand that is really T - 273.15 or whatever the shift is specifically. It is fundamentally an issue with the input being incompatible with the way standard mathematical operations would apply.
This is a common undergrad intro chem type issue stemming from the ambiguity PV = nRT since the units are unspecified and the unit conversion to K is not multaplicative
@b3m2a1 It's more of a type-error. degC isn't a scalar unit, but it's being treated like one. Neither (1 degC) nor (-1 degC) are scalar values, so it's inappropriate to apply scalar-division to them. By analogy, it's like saying "1"+"2"="3" when "1" and "2" are actually strings and their sum is "12", not "3".
@Nat Yeah but it's an input issue. Wolfram Alpha is doing what it can to infer your intent, but if you want to specify special info like that...well there's a reason programming languages were developed
It's okay, I was mostly just flabbergasted and interested in why a product like WolframAlpha would make such a basic, trivial error in interpreting common input. Seems like stuff like that should cause calculations to blow up all of the time.
In part, I don't think that many people use WolframAlpha like that. I think you've hit an edge case where you're trying to make WA work like an ersatz Mathematica and it just breaks down because there's not enough intent
I'm not sure if I understand the point about intent. "degC" isn't a scalar unit in any case, regardless of intent -- even if assuming that it's scalar doesn't blow up in the special case of some addition/subtraction scenarios, where it not causing an error is merely a happy coincidence rather than any sort of proper operation.
[WARNING: This is pedantic and possibly confusing.] On second thought, I should probably be more precise: "degC" isn't a scalar unit of temperature. However, it can be a scalar unit of deviation from 273.15 K. For example, ((10 degC) / 2) isn't (5 degC) if we're talking about temperature, but it can be (5 degC) if we're talking about deviation from 273.15 K (since half of the deviation of 10K from 273.15K would be a deviation of 5K from 273.15K). [...]
[...] However, the widely-accepted definition of the degC-scale is that it's as the Kelvin scale, but -273.15 to the magnitude. If the degC-scale is then understood as a unit of temperature-deviation, rather than a unit of temperature, then if we have some Kelvin temperature (say 283.15K) and note it as 10degC, then we divide it by 2, the resulting divisions would be different operations (halving temperature vs. temperature-deviation), and then the mapping that defines it would no longer hold.
Then it'd seem that we'd need to qualify that the definition of the scale isn't a conversion between two temperatures, but rather a mapping between a temperature and a temperature-deviation.
Then we'd have to deny that degC can be used in expressions where a quantity of temperature is expected, because degC wouldn't be a temperature but rather a temperature-deviation. And then we'd have to understand that scalar-operations to temperature-deviation values are meant as scalar-transforms to the temperature-deviation, rather than to the temperature.
Which, I guess, works.. but seems unnecessarily convoluted. So I mean, degC is a scalar-unit in the dimension of temperature-deviation, but it'd seem better to just focus on it being a non-scalar-unit in the dimension of temperature.
Okay, played with it a bit more... apparently WolframAlpha does have a concept of the two dimensions it's using. (heat capacity of water) * (0 degC), it pops up with a little box that says:
"Assuming degrees Celsius of temperature for "degC" | Use Celsius degrees of temperature difference instead", where the new URL refers to it as a assumption=%22UnitClash.. so a "unit clash", apparently.
So apparently WolframAlpha considers 10degC as a unit of temperature and as a unit of temperature-difference, and then it's attempting to infer which is meant from context.
Apparently it likewise has alternative interpretations of Kelvin and Rankine as units in the dimension of temperature-difference, where in that dimension, 0 Kelvin = 0 degC.
Okay, so for (1 degC) / (-1 degC), where we explicitly specify that it's degC-temperature (and not degC-temperature-difference), it gives 3 results: "-1 K/K", "-1", and "-100%". This is definitely a mistake since it explicitly specifies that we're talking about temperature (and not temperature difference).
@b3m2a1 Okay, I think I get what you mean about it inferring intent now. WolframAlpha appears to be aware of the ambiguity in using units-of-temperature also as units-of-temperature-deviation, and it has functionality to explicitly specify which and warns the user of its interpretation. That said, it's also buggy (e.g., it said that (1degC)/(-1degC) is -1 in the dimension of temperature; it also says the same in the dimension of temperature-deviation, where that result is correct).
Last weird thing (no links since they're not parsing correctly): all in the dimension of temperature:
* `(1 degC) / (-1 degC)` returns `-1`;
* `(1 degC) / (272.15 K)` returns `1.007`;
* the sum of these two, `((1 degC) / (272.15 K)) + ((1 degC) / (-1 degC))`, returns `2.015`;
* the difference of these two, `((1 degC) / (272.15 K)) + ((1 degC) / (-1 degC))`, is refused.
There's no ambiguity in the expressions because I'd had it explicitly set to the temperature-dimension, not temperature-deviation-dimension, which WolframAlpha explicitly recognized and warned about in a box above the results. So.. I'm guessing that WolframAlpha is incorrectly assuming that degC is scalar in the temperature-dimension, and that it gets the result right when mixed with K because it does a conversion to K, which is scalar in the temperature-dimension.
Each year, 73 billion students use Mathematica and the Wolfram Language at their universities. Okay, that might be an exaggeration, but as the person leading the Wolfram sales team, I see my group fielding questions from tons of students on their options for using Mathematica after they graduate. So perhaps it sometimes just feels like 73 billion. And that’s a good thing—we’re always excited t…
Given that I have a function $f$ with respect to $n$ variables $\lambda_1, \cdots, \lambda_n$. Namely,
$$
f(\lambda_1, \cdots, \lambda_n) \quad 0 < \lambda_i < 1
$$
Now I investigate one of its special cases, i.e., all the $\lambda_i$ is set to the same value.
$$
\bar f(\lambda) \quad 0 < \la...
