-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More complex units definition #26
Comments
This is true, but it is very simple to define new unit "fahrenheit". You then implement
There are two problems:
|
Here I added units for angle (phase) it is not yet ready for merging, and tests are missing: For now I used the quantity in the enumeration name in types.h, using the unit name seemed a bit strange, since unit names for angle do not have much in common. Did you have in mind a SCPI_Result* function, which would accept a unit and recalculate the value before printing it? I will have a look at the source to see if I can do this LOG/MUL/SUM unit recalculation without too much trouble. The inverse operation of log might not be obvious. If the base unit is not linear, POW should also be available. Regarding a use case, the user might wish to define the output amplitude of a signal generator in volts of decibel, depending on what is beeing measured. |
I prefer name of unit over name of measure. For everyone, base unit is different. Everyone in continental europe will use meter for distance, but everyone in US will use inches, etc. For me (european), "1 distance" will be 1 meter, but somebody in US will presume, that "1 distance" is "1 inch" and it is wrong approach. If the enumeration name will be SCPI_UNIT_METER, everything is clear for everyone. It is the same as "1 ANGLE". What does it mean? I think, that it is common to use "radian" or "degree". After looking into There is problem with "MIN" and "SEC", because it can colide with time.
There is already
I think, that we can produce some helper functions for conversions, but I don't like the idea of automatic non trivial recalculations while processing of the unit. So having conversion functions for dB, °C/°F, RAD/DEG/REV, etc. is nice, but doing this inside We can have table, how to convert some units to other units. This conversion table can support log/exp, multiplication and addition.
But I still think, that it is up to developer of the generator, how he internally represent output value. If he prefer dBV, it is his choice. I don't want to force him to use V, so he must recalculate it back to dBV to do some internal calculations. |
It is currently needed to expand all possible units, prefixes and suffixes.
It will be nice functionality to implement separate definitions of prefixes, separate definitions of suffixes, separate definition of units and connect it somewhare together.
The text was updated successfully, but these errors were encountered: