View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004783||PartDesign||Bug||public||2021-11-10 12:31||2021-11-22 18:18|
|Summary||0004783: Spreadsheet: Cannot Reference Cell(s) in formula|
|Description||if i enter this simple formula =B1 - 2 * tan(1 * B2) it doesnt work. result = Says "unit must be empty or an angle. in expression". The values in the cells are correct. but only if i manually put the value of those cells into the equation, then it will work. Like so =26.9 - 2 * tan(1 * 19) result=26.21|
|Tags||No tags attached.|
|FreeCAD Information||OS: Debian GNU/Linux 11 (bullseye) (KDE/plasma)|
Word size of FreeCAD: 64-bit
Version: 0.20.26306 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 6701788)
Python version: 3.9.7
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.3
Locale: English/Philippines (en_PH)
this problem also occurs when entering formula into a constraint in sketcher. same error is produced.
@sceptre357 : please always submit your issue to our forum first before opening a ticket according our reporting guidelines
Your issue seems to be that 'B2' is a quantity (value with unit) which isn't supported by 'tan' function. Also notice that you should ensure unit consistency.
So saying that both B1 and B2 are distances (in mm) you should enter '=B1 - 2 * tan (B2 / 1mm) * 1mm
Marking this ticket to be closed.
||Someone actually reads the tickets here, amazing. ill use the forum next time; though it didn't seem at all intuitive or obvious that all of the thousands of bugs in freecad need to be discussed in the forum fist before submitting. But it's your forum, run it however effectively or ineffectively you feel the need to.|
@sceptre357 : these are the rules at the moment. If you think they can be improved, please open a forum topic in "open discussion".
Actually the good point is that bugs in FreeCAD can be discussed. The main goal is to prevent false tickets, typically this one :
* Your problem has already been raised by others and solved in the forum
* This isn't a bug but an expectation of the formula mechanism that user ensures unit correctness and consistency
Will let this ticket open for a few days, please tell if my previous answer solved your issue.
||yes, it did solve the issue, and thank you for that. It was horrible going though the entire spreadsheet and every constraint to remove all units from all values interrelated with formulas to get the document to compute. Its also rather disconcerting that you cannot use any units for any values interrelated with a formula. Ether you dont use formulas at all or better hope all you units are the same. It was beyond my imagination that this was in fact the expected functionality and not a bug. So be it. You can just close the case.|
@sceptre357 : there is no other sensible way to do.
If you can use any unit, how would you interpret 'tan(1000 mm)' compared to 'tan(1 m)' ??? And is '1000 mm + 20 deg' different from '1 m + 20 deg' ???
Enforcing the user to be clear about its intentions is the only way. ;)
you asked a question then closed the ticket. reopening.
First of all sir thank you for commenting. You mentioned clarity of intent? ok lets talk about that. Presently, using a formula provides absolutely no way of specifying the unit of measurement whatsoever. The user is left to guess what unit of measurement is used because its unspecified anywhere; guessing doesn't sound clear to me.
And secondly, if you could specify m, mm or cm such as you put it, it would be a programmatic cakewalk to interpret the meaning and calculate accordingly. in fact you should even be able to specify inches in the formula if the user so desired and it be converted.
Thirdly, since measurements are often interconnected via constraints, its very likely to have a use case where different elements in a spreadsheet would preferably be expressed in different units of measurements; such as 12.42 meters rather than 12,420 mm or worse yet just 12,420. There's also the additional significance of error prevention by way of the users eye catching an out of place number or unit, you would largely lose this benefit in abnormal expression of measurements such as it's currently. Its always preferable to let the computer do the work so the user can maintain equilibrium.
I fail to draw the same conclusions as you, but then again my goal is to assist in creating a meaningful and efficient workflow that old and emerging FreeCAD users alike can easily assimilate. In all likelihood, allowing the user to maintain normal unit measurement specificity in spreadsheet cells and allowing those cells to seamlessly compute in a formula is the way to go.
If i ever had a recommendation or complaint, it would arise from a very typical use case and where I felt my workflow was unnecessarily bottlenecked or discontinuable. Im not here to nitpick.
||in fact your completely right in suggesting this be discussed in the forum first before opening a ticket. Its would have been useful to hear the thoughts of other users. Maybe ill do that and we can continue the discussion there with others.|
I closed after letting 2 days this ticket open because first time you replied in hours.
Anyway, discussions are to be held in the forum. ;) Your very welcome to open a thread there where you'll get lot more opinions.
|2021-11-10 12:31||sceptre357||New Issue|
|2021-11-12 02:19||sceptre357||Note Added: 0016025|
|2021-11-12 02:20||sceptre357||Note Edited: 0016025|
|2021-11-16 17:45||openBrain||Status||new => feedback|
|2021-11-16 17:45||openBrain||Note Added: 0016030|
|2021-11-16 17:45||openBrain||Tag Attached: #tobeclosed|
|2021-11-17 05:01||sceptre357||Note Added: 0016035|
|2021-11-17 05:01||sceptre357||Status||feedback => new|
|2021-11-17 08:17||openBrain||Note Added: 0016036|
|2021-11-17 09:18||sceptre357||Note Added: 0016037|
|2021-11-19 17:48||openBrain||Note Added: 0016040|
|2021-11-21 18:06||openBrain||Tag Detached: #tobeclosed|
|2021-11-21 18:07||openBrain||Assigned To||=> openBrain|
|2021-11-21 18:07||openBrain||Status||new => closed|
|2021-11-21 18:07||openBrain||Resolution||open => no change required|
|2021-11-21 18:07||openBrain||Note Added: 0016045|
|2021-11-22 02:29||sceptre357||Status||closed => feedback|
|2021-11-22 02:29||sceptre357||Resolution||no change required => reopened|
|2021-11-22 02:29||sceptre357||Note Added: 0016046|
|2021-11-22 02:33||sceptre357||Note Edited: 0016046|
|2021-11-22 02:36||sceptre357||Note Edited: 0016046|
|2021-11-22 02:37||sceptre357||Note Edited: 0016046|
|2021-11-22 02:44||sceptre357||Note Added: 0016047|
|2021-11-22 02:44||sceptre357||Status||feedback => assigned|
|2021-11-22 18:18||openBrain||Status||assigned => closed|
|2021-11-22 18:18||openBrain||Note Added: 0016048|