Computational Science also has matlab tag - but I wasn't sure whether I should mention that site. (I am not familiar with the site, so I don't really know what kind of questions it accepts.)
@CarlLange you have a web dev background, right? I was thinking about adding a professional string/localization management to one of packages I am working on. And web is a good place to get an inspiration from. I wasn't able to find a comprehensive overview of features and best practices. Only articles describing specific aspects. Do you know any?
So e.g. what should MyPackageString[token] support and what is a convenient way to setup sources for it etc etc.
Usually I'd just use the most popular or built-in-to-the-framework library, eg for react, github.com/formatjs/react-intl
To my eye it usually ends up just being a question of a dictionary somewhere with developer-written keys and translator-written translations. 🤷♂️
@MartinSleziak There are so many unhelpful responses on those questions that it makes me very glad to be a member of this community and not one of those...
So I have a bunch of lines that mostly overlap and then split off. I would really like to do something better than giving each line Opacity[0.2] to show clearly how much they overlap, because you lose detail after five overlaps. Does anyone know a clever way offhand?
@CarlLange You could rasterize the result and change an appropriate ColorFunction to cover a bigger range of colors than only gray tones
Alternatively, you could cut the lines into segments, do something like Counts[segments] and use the resulting information to adjust the thickness/style of each segment according to the count of that segment. This assumes of course that the segments of the individual curves are actually the same/similar enough to make grouping feasible and meaningful
If it is only for visual representation, then using a color gradient will help. Humans can differentiate between something like 20-30 gray values. But I'm sure that doesn't work for such small lines. If you have a rainbow gradient, that would help.
Is there a way to prevent unit simplification during unit conversions when possible, in order to avoid ambiguity? For example, in the following cases: 1) https://www.wolframalpha.com/input/?i=meter%2Ffeet+to+meter%2Fmeter 2) https://www.wolframalpha.com/input/?i=meter%2Fmeter+to+meter%2Ffeet
Intuitively people might expect (2) to be the inverse of (1)
I understand why the behaviour of (2) is correct though: the meter units cancel, and now the dimensionless quantity can just "become" meter/feet
I'm also wondering what this ambiguity means mathematically when considering mathematical properties of dimensional analysis (for example, the abelian group described in en.wikipedia.org/wiki/…)
Regarding the ambiguity: There really is none - 381/1250m/ft=1m/m=1, and 1250/381m/m=1m/ft=1250/381 are both correct in a strict mathematical sense
The group described in the wikipedia article does not really apply here - there, only abstract units like length or time are considered, not concrete units like meters or feet
All quantities in your example have the same unit, i.e. 1 (i.e. L^0*M^0*T^0…) in the sense of that group
You can also ask Mathematica to convert the quantities above to SI units:
Right, I agree both conversion paths are correct so maybe ambiguity isn't the best word for it
I was considering the quantities in my examples to each be L^1/L^1, with the solution varying dependent on whether they're immediately simplified to L^0
I was misunderstanding the WolframAlpha result in the second case -- I thought the unit was still implied, but the displayed result actually means 1 (unitless), not 1 (meter/feet)
