>> Could the ezunits database be extended somehow to separate (most) SI prefixes from SI units, and combine them as needed? For example, having “kilo-” and “k-” prefixes with a value of 1000, so that “kilometer” would be parsed as a combination of “kilo-” and “meter”, and “km” as a combination of “k-” and “m”, rather than requiring separate database entries for every combination of SI prefix and SI unit?
>
> I have thought about that sometimes. The advantage that I see is that it would make it more succinct to declare SI units, since it would obviate the need for stuff like 100 cm = 1 meter and so on. But it wouldn't make it any simpler to work with units, I don't think — it's not any more convenient to write milli*second than millisecond, and m*s is ambiguous, because m might be milli and it might be meter.
I was thinking about prefixes purely from the database perspective, not about users explicitly specifying them as products. My thought was that users would still use e.g. either “millisecond” or “ms”, but the database entries would contain “milli-”, “m-”, “second”, and “s” rather than “millisecond” and “ms”, and the supporting functions of the ezunits package would combine “milli-” * “second” as “millisecond”, and “m-” * “s” as “ms”, behind the scenes. A user-entered “m*s” would still be interpreted as “meter-seconds” by the package, and a user specifying a prefix by itself in a term would not be recognized as a unit. A user-specified “milli” by itself in a term would be unrecognized, and a user-specified “m” by itself in a term would always be recognized only as “meter”.
> Maybe it would be possible to automate the standard SI prefixes, so that at least the declarations for SI units would be a lot more concise. But most of the time, most users won't want to look at that stuff, so it's not a big win.
My goal was purely the former; I didn’t conceive of users being at all interested in looking at that stuff. The “big win” would be the conciseness, so that explicit unit entries wouldn’t be needed for the SI base and derived units (7 + 22 = 29) multiplied by all of the SI prefixes plus the lack of a prefix (24 + 1 = 25) in both spelled-out and abbreviated forms (2) = 1450 entries, plus two extra for explicit “kilogram” and “kg” entries = 1452 entries, vs. only (29 + 24)×2 + 2 = 108 entries needed with an automated prefix capability.
_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.