newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[matthiaspaul]

(10-22-2015 09:43 PM)Claudio L. Wrote:  

(10-22-2015 08:50 PM)matthiaspaul Wrote:  Actually, I think, prefixes are so fundamental, the system should ideally support them both (decimal per SI/ISO and binary per IEC/IEEE/ISO) by default.

I understand your point.
Decimal prefixes are used for many units, consistently as per SI specifications, therefore it makes sense that the system supports them automatically, as the effort of entering 20 units for each unit you want to define is significant.
Binary prefixes on the other hand, are only used on one unit (byte). For that one particular case, there's only a few units that need to be defined (8), so I'm not sure I can justify the speed penalty in the system to scan for those prefixes on every single operation involving units.

In IEC 60027-2 the binary prefixes were still restricted to units of information storage, but AFAIK ISO/IEC 80000-13, which incorporates the SI decimal as well as the IEC binary prefixes into the ISQ system, no longer has this restriction, that is, it is possible to apply binary prefixes to other units as well - and it even makes sense for a number of things outside of information technology. F.e. a frequency ten octaves above 1 Hz is 1024 Hz (the value must be doubled for each octave, so ten octaves represent a factor of 2^10). 1024 Hz = 1.024 kHz = 1 KiHz (or 1 kiHz - both are valid).

Another potential use of binary prefixes could be in conjunction with the TU (time unit), a unit of time defined in the IEEE 802.11 standard as 1024 µs.

(10-22-2015 09:43 PM)Claudio L. Wrote:  

(10-22-2015 08:50 PM)matthiaspaul Wrote:  - allow to specify a "preferred" target prefix to be used in results (would need some system to resolve conflicting preferences for different units). The system would still allow to convert into something specific, but would default to preferred units otherwise (f.e. 'm?m' UDEFINE would return results in mm, even if given in cm or m etc. or 'Gi+x?B' UDEFINE would return results in GiB even if given in GB, whereas 'G+xi?B' UDEFINE would return results in GB even if given in GiB.)

(The syntax is just a rough proposal to illustrate the idea, nothing "finished".)

I like the "preferred target unit" idea, perhaps as an attribute of a variable, not of the unit per se. I'm not so sure how to implement something like that yet, I'll have to give it some more thought.
Regarding the additional syntax, 'G+xi?B' looks like a Regex expression, a user would only be able to use that with the manual in hand, or more likely will never use that feature.

I agree. Of course, that ad-hoc "syntax" is cumbersome and incomplete. For example, it misses a syntax to remove attributes from or add attributes to existing definitions without having to repeat the whole definition (something like setting bit flags in C via |= etc.).
Ideally, there would be some short notation for experienced users (to safe keystrokes when entering it on the calculator) and a longer, more "symbolic" representation for readability in programs and when writing programs externally.

Regarding applying attributes to units or variables, I think, both might make sense depending on the situation. Under the pre-requisite that there is some easy means to redefine and overload existing definitions (in order to minimize the risk of accidently screwing up the "core definitions"), there are scenarios where a user might know that s/he needs specifically prefixed output units for a while, so putting such preferences into the unit definitions directly (or something else that affects the units individually) might be easier than defining the preferred format for a variable. Also, this continues to work for immediate number-crunching without using variables at all.
In other situations, it might be convenient to attach preferred output formats to variables. If both were defined, preferred formats for variables should certainly override preferred formats for units.

Greetings,

Matthias