Suggestion: Add cycles/turns to the available units for angular dimensions.

[WraithGlade]

Hello again! I've been having fun learning the program from the official book today!

Anyway, I thought of another idea that I'd really like to see:

It would be great if cycles (aka turns) were available as a unit for working with angles.

1 cycle (aka turn) is 360 degrees.

I usually find that I think most naturally about angles in terms of what proportion/"percentage" around a circle I'm moving.

For example, I usually think things like "I want to rotate 1/4 of the way around the circle" and then mentally translate that to 90 degrees, but it would be nice if I could just input the 1/4 directly (either as decimal or even better yet as a fraction that is directly translated by QCAD).

Having to translate that to other units such as degrees or radians adds an extra barrier to ease of expression of concepts.

Cycles (aka turns) may be less common but they are a wonderful unit of angles that should be more often used.

Cycles have a direct correspondence to 1 tau (2 pi) and thus have good mathematical properties too in addition to their intuitive advantages.

I want to be able to express any arbitrary fraction of a circle of rotation instantly instead of having to do any mental translation at all.

That would be a great thing to add to QCAD I think.

Thanks for your time and efforts and for reading.

[Husky]

Hi,

For example, I usually think things like "I want to rotate 1/4 of the way around the circle" and then mentally translate that to 90 degrees, but it would be nice if I could just input the 1/4 directly (either as decimal or even better yet as a fraction that is directly translated by QCAD).

Most input fields accept Arithmetic operators. If you need a Quarter of a circle just type in
360/4. Same would work with 360/60 or 12*3 etc..

[WraithGlade]

Thanks for the information. That will be helpful of course.

I do still think that having cycles (a.k.a. turns) added to the available units would be beneficial though.

I was wondering though what "surveyor's units" are. I've not heard of those until browsing QCAD's interface. Any relation to cycles (a.k.a. turns)?

Anyway, thanks again and have a great day/night!

[Husky]

I do still think that having cycles (a.k.a. turns) added to the available units would be beneficial though.

I have the feeling we are used to different geometrically terms. Sorry but I don't understand your terms.

A circle is a circle. Ok!
What is a turn? An arc? Why a.k.a circle? Means that a turn is a circle? Confusing to me!

[CVH]

Suggestion: Add cycles/turns to the available units for angular dimensions.
. . . . .
It would be great if cycles (aka turns) were available as a unit for working with angles.

The suggestion in the title relates to Angular Dimensions entities.
> These can be configured under Drawing Preferences .. Dimensions .. Dimension Settings .. Label Format .. Angular Dimension .. Format
. . . . .
Later explained as 'working with angles'.
> What would relate to input fields and/or the angle properties in the Property Editor.

Properties do not display units, basically CAD is unit-less ... Plain values.
The GUI default for angles are degrees and that is in decimal notation, internally it uses radians.
This will not change anytime soon unless the SI standards alter.

Under QCAD one can however enter angles in several distinct formats ... Usually case insensitive.
- Decimal degrees e.g. 123.45 or 123.45°and depending the Local format that may be with a comma instead of a dot.
- Explicitly indicated degree e.g. 123d27'0"
- Explicitly indicated bearing e.g. 326b33'00"
- Decimal radians e.g. 2.15461r
- Decimal gradian, grad, gon e.g. 137.16667g
- Surveyor notation e.g. N33°27'00"W or N33D27'00"W, etc.

In turns or tau that would be 0.342916667T but I don't consider this to be more clearer or even meaningful.
OK, just over 1/3 full turn .... But for me 1/3 is 120° and it is 3.45° more ... Just over 1/3.
Also remind that 1/4 turn would be represented by 0.25T and automatically converted to 90.00 for input fields.
1/8 turn >> 0.125T >> 45.00 and in a similar way 5 degree would be 1/72T.

Main question: How often are angles real fractions of a turn
-> For some users always, for others that are the exceptions.

Also drop the terms turns and cycles as being plural ... Angles are always limited and presented normalized.
75266164 degrees is a valid entry but turns out to be nothing more than 244 degrees.
There is no angle with 209072 + 61/90 windings, it results in 61/90T or 0.67777...T what doesn't tell me anything.

I was wondering though what "surveyor's units" are. I've not heard of those until browsing QCAD's interface. Any relation to cycles (a.k.a. turns)?

Standard Math zero degree is right, increasing in the CCW direction.
For surveyors zero = North = up, increasing in CW direction.
Then there is also the notation as xx (<90) degrees from N to W, from N to E, S to E or S to W.

Regards,
CVH

[WraithGlade]

Hello everyone, sorry for the delay of a couple days. I only just now found the time to visit the forum again.

In response to Husky:

A less commonly used (but I'd argue one of the most natural) units for measuring angles is often called a "turn", such that 1 turn is a full revolution around a circle. The word "turn" however implies a physical geometrical context however, whereas the concept of any entity revolving in any kind of cyclic process can be more generally referred to as a "cycle" and hence I prefer to refer to the unit that way since it is more universally appropriate and reflects a broader understanding of the generality of the concept.

Cycles (or turns... whatever you want to call them) are exceptionally natural and flexible as units because (1) it is often most natural to think of what proportion of a full turn around a circle you want to travel and (2) any other angular unit can be expressed in cycles with the least possible amount of extraneous factors (such as dividing by other numbers to remove or renormalize any other unit, such as degrees).

For example, 1 degree = 1/360 cycle. Notice that cycles thus directly express exactly what is going on. A degree is a unit that rotates you 1/360 around the circle. Also, the use of a tau based unit causes extra coefficients to drop out of the formulas for measuring the volumes of shapes.

You know how lots of math formulas for volumes of shapes have extra factors in them like 2 and 4 and 8 and so on? That's because the number pi is less natural and when you use tau (a full circle) instead then the tau contains those factors already, which results in a math formula for volumes that is more structurally natural, easier to remember, and evolves when the shape is changed in a slightly more predictable way.

Any other angle unit written in cycles always turns into a very direct representation, because tau (in correspondence with a full cycle) has special mathematical properties that no other choice of angular unit has, resulting in maximally clean and easy to use formulas free of extraneous coefficients and the associated unnecessary busywork they embody.

Cycles are seldom ever available in software, but they are nonetheless one of the best units.

I would perhaps even go so far as to say they are the most natural unit of angles in existence.

The fact that we use a decimal fractional system and that software converts to that automatically is incidental and is not actually an aspect of cycles themselves.

For example, if the software automatically converted to fractions (rational numbers) then the cycles would not have odd-looking decimal expansions and their natural qualities would be more readily apparent. The use of decimal fractions just partially hides the underlying wonderful nature of cycles as a unit, essentially.

Even regardless of that though, it would still be nice to have cycles as a unit, even if it is forced into decimal, because it provides one more useful tool.

Even in decimal form the cycle units are much easier to think about to me than having to convert the more arbitrary (though more popular) units.

That's just my opinion on it though. Nobody is trying to stop anyone else from using their own angle unit preferences, but rather just to support one new unit type.

I just really wish cycles were available too. It would save time sometimes and I've always found it far more intuitive than other units.

Thank you for your time and for reading!

In response to CVH:

Thank you for explaining all that to Husky and for your other comments and time regarding everything I said.

Thank you for the explanation of the surveyor's units too!

I'm not sure what you mean by the cycle units "not telling you anything" though.

Even just the fact that cycles make it instantly apparent exactly what proportion of the circle you've traversed (e.g. 0.3 being 30% around the circle) is immensely helpful and saves a lot of time for people (like me) who haven't spent decades getting used to degrees and can't instantly translate degree calculations in our heads.

Also, large angle measures are only equivalent to smaller ones in the absence of time and movement. The only reason you can treat them as "the same" is because time and motion are not involved, but in some cases they could be.

75266164 degrees of rotation per second is quite different from 244 degrees of rotation per second.

The main value of having cycles available though is simply in the fact that it makes it immediately apparent how far along the circle has been traveled.

Almost everybody in society understands percentages and proportions instantly, but only a small fraction of people have an instantaneous ability to mentally translate degrees and other common angle units into the corresponding actual physical meanings.

In other words, for anyone who understands what cycles are, the overwhelming majority of people will already have almost perfect number sense for their meaning, whereas their number sense for other angle units will take many years to build up to any similar level. Everybody already knows how to think about percentages and proportions.

Anyway though, thanks a bunch for all your time and efforts and for talking with me!

Regardless of whether QCAD implements cycles (or turns), the software is of course wonderful and very exciting for me to have now and the arithmetic trick can at least let me work around the lack of availability of the most natural angle unit (cycles).

PS: I'll be back later to respond to the other suggestion thread I made. I'm eating dinner soon.

[CVH]

I don't think that I needed to explain anything to Husky ... I gave examples of all supported input methods for angles.
All result in an 123.45 degrees angle.

Remark here that I consider values in degrees to be functional or almost correct when there are at least 8 decimal digits.
6 digits for radians, in the same order Tau would require at least 10.5 digits.

Sorry to say but 5 degrees has a meaning for me, I can not quantify 1/72T.
1/3, 1/4, 1/5, 1/8, 1/10, 1/12 are OK but 1/72 or 61/90 do not.

My question remains: How often are angles real fractions of a turn
For you probably always, in my case almost never.
It matters that an angle is not 90 but 90.000003245 degrees, we have different playing fields.
When in decimal notation one has still have to make a mental conversion, 0.342916667T or 34,3% of a turn.
No, not all people have a good notion of what % are.

Degrees of rotation per second is an angular velocity ... This has nothing to do with drawings in 2D.
Per time is in fact the fourth dimension.

I'll repeat:
QCAD Properties do not display units, basically CAD is unit-less ... Plain values.
The GUI default for angles are degrees and that is in decimal notation, internally it/QCAD uses radians.
This will not change anytime soon unless the SI standards alter.

QCAD exploits the double Floating Point notation.
More accurate Math can be preformed by applications that exploit fractions, fractions of BigInt.
But that is not the mathematical base used in this case.

Regards,
CVH

[WraithGlade]

Thanks for clarifying what you meant. I appreciate all your efforts in talking to me (etc).

I'm still not sure what you mean by "I can not quantify 1/72T" or similar notions.

If QCAD uses radians internally (like most software) then any units that are in degrees will also have floating point round off error just as much as cycles (turns) would. I even have a degree in computer science, so its not like I'm unaware of how numerical computation works on a computer.

Interesting random trivia sidenote: I've heard once that GPU's trigonometric functions on computers actually internally use a mapping structure that uses cycles (a.k.a. turns) and have to convert back and forth between other units every time (wasting computational time in the process) because cycles (turns) are such a natural unit for computation when fully embraced. If people used cycles instead of degrees or angles, 3D video games could rotate objects a bit faster (or with less wasted energy per operation on the processing chip).

1/72 just means one 72nd of the way around the circle. It would be meaningful if you wanted to evenly space 72 objects evenly around a circle for example. All fractions of a circle are arbitrary in that sense. I don't understand what about that you're saying can't be quantified. There may just be a translation/communication barrier here.

Cycles themselves and decimal approximations of cycles are also conceptually different things. The fact that cycles in decimal notation sometimes look uglier is not the fault of cycles as a unit. Those are independent (i.e. orthogonal) factors in what the result looks like superficially. Indeed, the exact same point (your criticism) could be made about radians and yet most software uses radians for internal trig implementations, yet doing so causes no harm despite that fact and despite the decimal expansions that result. The same would be true of cycles, as with all other units that are forced into the underlying binary approximations of decimal values.

Also, I am confused by the claim that QCAD is unitless.

In the very next sentence you say that QCAD uses radians internally and degrees are the default for units and also seem to always be what shows up in the property window (despite them not being the internal unit) even when I switch the document to use other angle units.

What is the harm in allowing angles to be displayed in the viewport status bar in cycles (turns) and elsewhere?

All it would require is the same kinds of computations to convert units that QCAD already does for a variety of other units.

Some parts of what I've said in my comments are about the underlying principles of cycles and other parts are also relevant to QCAD itself.

I wasn't ever assuming that all aspects of cycles would be implemented everywhere in QCAD. I was merely explaining why cycles are a good unit of measurement from a first principles standpoint, to ensure you understand the big picture of why someone would want cycles (turns) in general.

I don't see why cycles (turns) can't be integrated just as much as the other displayed unit options for the status bar (etc) considering the other units already do that and the internal angles of QCAD presumably wouldn't need to change extensively nor would what I've suggested thus cause any real extensive changes assuming the software is architected sufficiently to support new display units, which it probably is.

Perhaps we may just have to agree to disagree.

I still don't understand why merely adding in another displayed unit would cause prohibitive problems.

The other units didn't break the entire system when they were added did they?

Well, cycles are just yet another variant of scaling of those angle values to convert units.

As a computer programmer myself (though not familiar with QCAD's codebase) I see no real barrier to it. Indeed the implementation would/should likely be relatively easy, unless there are tons of hardcoded units throughout the entire codebase, which seems unlikely.

Anyway though, I wish you the very best of nights and thank you very much for your time and for talking with me!

I'm excited to use this wonderful software, regardless of whether you guys implement any of my suggestions!

It is shaping up to potentially become one of my favorite programs!

It is truly a masterpiece of thoughtful user interface design and useful functionality!

[WraithGlade]

Hey everyone and wonderful day to all!

I had another random related thought connected to this discussion and just thought to append it here:

There are only three angular units that I know of that occur in nature (i.e. that are not human-made arbitrary constructs):

• radians (or alternatively conceivably a diameter-based equivalent, instead of radius-based, but that's a trivial difference)
• cycles (a.k.a. turns or revolutions)
• complex numbers (though complex numbers are more a measure of orientation than of rotation, since a complex number can't store multiple revolutions, i.e. you can't say "3.5 turns per second" via a complex number because it can only represent the orientation aspect of angles and not variance over time)

All three of these units repeatedly naturally spontaneously appear in calculations in some form even if you try to avoid them.

They are like the angular analogs of other kinds of naturally occurring mathematical constructs, such as the natural number e for example or various other naturally occurring constants and/or concepts.

So, seeing as these all three have a fundamental natural nature and are part of the underlying property of the universe, shouldn't they always be available?

Any given civilization may create some other arbitrary scaling factor for measuring angles, but the only angle units I know of that spontaneously occur in nature that I am aware of are these three.

This is another great reason why cycles should be added I think!

There's also a fairly good Wikipedia page that covers the merits and special qualities of cycles (a.k.a. turns or revolutions) that may be worth reading some.

Indeed, thinking of this has also given me another related thought, that of suggesting one more missing unit!: complex numbers via normalized unit circle coordinates. That'd be a helpful unit to display under some circumstances too potentially.

I will create that additional idea as a separate thread shortly though, to avoid confusion and putting to much in here.

Anyway, as always you have my gratitude for creating and maintaining this awesome software and for taking the time to read my thoughts and consider anything I say!

Thanks a bunch and have a great day/night/etc, as always!