View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002626 | FreeCAD | Bug | public | 2016-07-17 11:11 | 2016-08-11 17:02 |
Reporter | m42kus | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | Linux | OS | Arch Linux | ||
Fixed in Version | 0.17 | ||||
Summary | 0002626: Quantity's UserString doesn't honor Unit System | ||||
Description | Unit System is set to: "Standard (mm/kg/s/degree)". The UserString isn't consistent with the set Unit System with the signature (-3,1,0,0,0,0,0,0). I havn't experienced the same behaviour with any other signature up to now. However, __str__ does always honor the Unit System in this case. According to the wiki (http://www.freecadweb.org/wiki/index.php?title=Quantity) UserString should use the unit set as the Unit System in the Settings. | ||||
Steps To Reproduce | >>> Quantity("5 kg/m^3").UserString u'5 kg/m^3' >>> Quantity("5 kg/mm^3").UserString u'5 kg/mm^3' >>> Quantity("5 g/mm^3").UserString u'5 kg/cm^3' >>> Quantity("5 kg/m^3") 5e-09 kg/mm^3 >>> Quantity("5 kg/mm^3") 5 kg/mm^3 >>> Quantity("5 g/mm^3") 0.005 kg/mm^3 | ||||
Tags | No tags attached. | ||||
FreeCAD Information | |||||
|
No, this is not a bug. When writing e.g. "Quantity("5 kg/m^3")" then internally it *always* computes the values in mm, kg, s -- independent of the used unit in the expression and independent of the set unit system. However, the UserString tries to return values that are not too low or too big. Therefore it uses the corresponding prefix for a unit. So, if you e.g. write Quantity("10000 mm").UserString then instead of 10.000 mm it says 10 m. Also important for the user string is that it follows the locale settings. If e.g. the decimal separator is a comma then it returns 10,000 m. Furthermore it follows the number of digits the user has set in the preferences. The main purpose of the user string is to represent the quantity in a GUI widget, it should be avoided to do any calculations with it because it may cause huge round-off errors. |