Could use support for engineering decimal units

[Joel_graff]

git commit 00e6e376c9 and git commit 99074228.

In today's FreeCAD-daily.

Sweet!

[Joel_graff]

l/c 'm' is taken for metres, l/c 's' is taken for seconds(time), so I'm going with 'M' & 'S' for now. We're definitely getting closer:

...

Seconds are displayed using the global decimal place setting. Do you need decimal place on Seconds? Looks ugly to me, but that's just aesthetics, not functionality.

So I've set the document units to Imperial Civil and tried entering an angle, but it defaults to decimal degrees. The FPO property is App::PropertyAngle...

Am I missing something?

Captre.JPG (53.4 KiB) Viewed 242 times

[wandererfan]

So I've set the document units to Imperial Civil and tried entering an angle, but it defaults to decimal degrees. The FPO property is App::PropertyAngle...

Am I missing something?

It appears the PropertyEditor data entry field for angles doesn't know about Units. The degree sign is hard coded.

Might take me a bit to figure this out.

[wandererfan]

Created issue #3726 so this doesn't get lost.

[Joel_graff]

It appears the PropertyEditor data entry field for angles doesn't know about Units. The degree sign is hard coded.

Might take me a bit to figure this out

Ok, thanks.

On the unit symbology note, I started poking through the Quantity / UnitSchema code just to get acquainted... The lexer / parser stuff is entirely foreign to me (I'm still having nightmares from coding a parser in Boost several years ago), but I feel like the solution lies in providing a 'context' for quantities so that quantity units (names / symbols) only need be unique within that context.

Examine DMS angles. It's immediate 'context' is an angular measurement (alongside decimal degrees and radians). But, DMS units also use a temporal quantity's units (minutes / seconds), and denotes them with symbols that are associated with a length quantity! I suppose it's a bit of an edge case, but I suspect accommodating this would probably deal with a lot of other potential unit symbol / name collisions as well.

So, maybe a single layer of abstraction is in order to help fix this? That is, we add a "quantity context" class that subclasses Quantity, and the specific unit-quantity class then derives from the context class. Thus, Quantity::Foot becomes Quantity::Length::Foot.

But I don't know if that's really necessary, because I see that in QuantityParser.l, there's a series of lambda's or functions that are defined, beginning with the unit symbol as a string token:

Code: Select all

"M"        yylval = Quantity::AngMinute;           return UNIT; // minute(Angular)
"S"        yylval = Quantity::AngSecond;           return UNIT; // second(Angular)

Maybe just encoding the context in the symbol token (and adding the necessary handling code in the lexer) is possible? Or adding an extra field prior to the unit symbol token that is just a unique ID?

For example to re-use the foot symbol for angular minutes:

Code: Select all

"Angle::'"        yylval = Quantity::AngMinute;           return UNIT; // minute(Angular)

or

Code: Select all

"Unit_id_here"       "'"        yylval = Quantity::AngMinute;           return UNIT; // minute(Angular)

[wandererfan]

The lexer / parser stuff is entirely foreign to me (I'm still having nightmares from coding a parser in Boost several years ago), but I feel like the solution lies in providing a 'context' for quantities so that quantity units (names / symbols) only need be unique within that context.

Yeah, I was thinking of "context" as a way to distinguish 'minutes from 'feet. Should be able to figure it out from the type of unit length/feet, angle/minutes. But I didn't get into it very far.

Anyway, found a fix for the property editor:

DMSinPE.png (31.33 KiB) Viewed 172 times

but Expressions with dms don't parse, so I'll have to learn a bit about that area.

[Joel_graff]

Yeah, I was thinking of "context" as a way to distinguish 'minutes from 'feet. Should be able to figure it out from the type of unit length/feet, angle/minutes. But I didn't get into it very far.

Ok. If you get some time to think about the problem a bit more, keep me updated - it'll give me a chance to learn something and maybe help out a bit.

but Expressions with dms don't parse, so I'll have to learn a bit about that area.

Just like fixing up an old house... Every improvement exposes more problems!

[wandererfan]

According to this https://en.wikipedia.org/wiki/Minute_and_second_of_arc, the proper symbols for arcminute and arcsecond are:
- ′ ′ ′ prime symbol for minutes (no key for ′ Shift+Ctl+u 2032)
- ″ ″ ″ double prime symbol for secs (no key for ″ Shift+Ctl+u 2033)
and apostrophe and quotation mark are substitutes.

How do you feel about using those as unique display symbols for ddmmss angle measurement?

We'd need to keep M&S for data entry(?) like we have "deg" as a data entry substitute for
- ° degree symbol (no key for ° Shift+Ctl+u 00b0)

or teach the world how to enter unicode from the keyboard.

[Joel_graff]

How do you feel about using those as unique display symbols for ddmmss angle measurement?

We'd need to keep M&S for data entry(?) like we have "deg" as a data entry substitute for
- ° degree symbol (no key for ° Shift+Ctl+u 00b0)

or teach the world how to enter unicode from the keyboard.

Hmmm.. The wikipedia article provides a nice dodge to the issue, I'll hand you that. Anyway, I'm fine with that.