Originally reported on Google Code with ID 189
Hi, Congratulations for speedcrunch, it's the best desktop calculator I've ever seen! I would like to suggest to implement support to work with minutes and seconds when doing trigonometric operations and the degree mode is active. For example, accept sin(30') to calculate sin of 30 minutes, or sin(30'') (or sin(30")) to calculate sin of 30 seconds. Cheers, Alexandre
Reported by alexandrezabot
on 20080515 15:13:23
Comments (26)

Account Deleted 
Account Deleted ``` Hi Alexandre, thanks for the suggestion. ```
Reported by `helder.pereira.correia` on 20080515 15:31:30  Labels added: TypeEnhancement  Labels removed: TypeDefect

Account Deleted ``` More generally, being able to manipulate numbers in sexagesimal format would be useful: for example, adding or subtracting times is an operation I do sometimes when I am preparing a recording or generally manipulating sound files. I suggest sexagesimal could be a format just as currently SpeedCrunch recognizes binary, octal, decimal and hexadecimal. How sexegesimal numbers should be written remains to be defined, though. should 1 hour 2 minutes 3 seconds and 4 hundredths of seconds be written 1°2'3"4 (closer to angle notation) or 1:2:3.04 (what ISO suggests for time)? ```
Reported by `davitofrg` on 20081105 17:11:58

Account Deleted ``` @davitofrg: wouldn't a specialized dock widget or whatever to calculate time fit the purpose better? ```
Reported by `helder.pereira.correia` on 20081105 17:19:35

Account Deleted ``` Congratulations on a great project. On the subject of minutes and seconds, in my work I do many calculations in Degrees,
Minutes and Seconds. It is a pain to convert these to decimal first and an even greater oain to convert the result back to Degrees, Minutes and Seconds. Is there any chance that input in Degrees, Minutes and Seconds could be added to SpeedCrunch. Thanks, Ron ```
Reported by `ourfamilyscene` on 20090212 03:45:26

Account Deleted I too would love to have the ability to work in and convert from/to degrees, minutes, seconds, both for angular measures and time calculations. So, I'm just adding my support to this request. Thanks, Peter, NZ
Reported by
nzpete54
on 20150610 01:29:12 
While the notation
1°23'45.6"
is certainly common, I'm not sure I'm sold on it for SpeedCrunch. I see a lot of potential for trouble using it. For once, it can be used in a multitude of variations (omitting e.g. hours or minutes), and the separators (°
,'
,...) can either be used as infix or postfix operators (°
resp.'
in1°23'
). Finally we'll have to deal with a lot of new tokens:
°
orh
for designating full units, 
'
,m
for minutes, 
''
,"
,s
for seconds,
and all possible combinations of those need to yield defined behavior. (The problem with the notation is that it contains an implied addition,
1°+23'
, while generally in mathematical notation only multiplication can be implicit. I don't see an easy way around this.)The notation
1:23:45.6
on the other hand seems very appalling. I can think of no possible ambiguities. Plus, by interpretinga:b
simply as an infix notation fora + b/60
, it should be super easy to implement. Precedence: lower than addition. Granted,0:0:30
still takes longer to type than30"
, and arguably more than30/3600
, but the idea sounds reasonable to me.Finally for displaying the output in sexagesimal format we'd need a function like
sexa
to do the job. I assume there is no need to display the resulting 'digits' (i.e.1
,23
and45.6
in the above example) in any base other than decimal, so introducing a new value for the format (e.g.'s'
) should be fine. 

Issue
#536was marked as a duplicate of this issue. 
Issue
#407was marked as a duplicate of this issue. 
Plus, by interpreting
a:b
simply as an infix notation fora + b/60
, it should be super easy to implementUnless someone else is already working on this, I would like to try it. Approach above sounds quite good (it would need right associativity however to handle
a:b:c
correctly). An alternative could also to interpret asa * 60 + b
, which would mean the result is always expressed in terms of the smallest unit. The first version seems however more intuitive and useful to me.On the other hand, interpreting as
a * 60 + b
makes output handling easy  you just interpret the integer part of the result as a sexagesimal number, and you get what you insert for botha:b:c.d
andb:c.d
.With the
a + b/60
interpretation the output handling is a bit more difficult. ifa
is the integral part, how do you choose if you want the fractional part to be written asb:c.d
, orb.d
? That would need either two separate output formats, or a selector like decimal fractional parts. 
Sure, go ahead.
Right, I had missed the issue with associativity... Well, that's not going to be overly pretty... unless you come up with a nicer way to treat right associative operators ;)
An alternative could also to interpret as
a * 60 + b
Do as you prefer :) You are in charge.

In fact, I have an idea how the associativity stuff could be dealt with.
Write a function like
bool comparePrecedence(Operator left, Operator right)
. Whenleft
andright
are different operators, returntrue
ifleft
has higher precedence thanright
. If both are the same, returntrue
if the op is left associative.false
otherwise.Could work, right?

Another option (and perhaps nicer) is not to make it operator at all, rather part of the numeric literal parser. I doubt we need something like (1+5):(209).

Thinking more about it, the interpretation as
a + b / 60
seems more useful to me, as this is what you need to perform the degree computations. As it also seems more natural to me, I will try this first  probably with the numeric parser approach, not an operator.I am starting experimenting with output formatting anyway.

Hmm, the literal parser is already cumbersome enough. I'd prefer to treat it properly as the operator it is. Opinions? Mainly @thadrien, @teyut.

While
sexagecial
is correct and sounds coolImo it sounds wrong. Do you mean
sexagesimal
? ;)This is accurate for angular values, but not always for time based calculations where a minute may be chosen as a basic unit.
I see. Do you intend to implement both formats to be accessible via different functions, or have one function and a settings switch?
I suggest small numbers (below resolution of the fractional seconds) to be displayed as all zeroes, but if desired, any number below a second could be displayed as 0:00:<value in seconds>, where value in seconds may be scientific.
Sexagesimal notation should not automatically round the result to zero. I'd definitely prefer the latter approach.
One final note: The label 'Fraction as minutes' is not really intuitive. It took me a second to see what you mean. Maybe a description like 'minutes:seconds' and 'hours:minutes:seconds' would make it clearer to the user?

Do you intend to implement both formats to be accessible via different functions
Two different functions seems more appropriate to me.
'minutes:seconds' and 'hours:minutes:seconds' would make it clearer to the user?
Good idea, only I am not so sure about "hours". Perhaps "Degrees" would be more appropriate for the calculator?

I have introduced the formatting options into the menu and functions, which was the easy part.
Then I have tried to implement the output formatting itself, but I am afraid I am more or less stuck.The output formating seems to be very strictly oriented to integral.fractional style outputs (cf. intpart / fracpart of many structures) and making it to output number split into more parts seems like a more difficult undertaking than I expected.
On https://bitbucket.org/Ondrej_Spanel/speedcrunch/branch/minSec you may check my effort so far. If you have any advice or critique to that, feel free to write.

For me it fails to build.
..\src\math\floatconvert.c: In function '_outmins': ..\src\math\floatconvert.c:767:3: error: incompatible type for argument 2 of '_setfndescmins' _setfndescmins(n, fmins); ^ ..\src\math\floatconvert.c:234:1: note: expected 'floatnum' but argument is of type 'floatstruct' _setfndescmins( ^ ..\src\math\floatconvert.c:767:3: error: too few arguments to function '_setfndescmins' _setfndescmins(n, fmins); ^ ..\src\math\floatconvert.c:234:1: note: declared here _setfndescmins( ^ Makefile.Debug:7161: recipe for target 'debug/floatconvert.o' failed

I have fixed the build, but I did not intend the sources for building, rather for a code review of the changes. The output format is certainly not working (output mode selection is, but that is the easy part).

Is there a specific reason for using minutes as the base unit instead of seconds? Is the fractional minutes notation (
hh:mm.frac
) that common?Also, I believe the main purpose of that issue is to support degrees in trigonometric functions, so there should be a conversion to radian somewhere (using units?).(edit: it's already implemented, doh!)Hmm, the literal parser is already cumbersome enough. I'd prefer to treat it properly as the operator it is.
I think it should be part of the lexer (
Evaluator::scan()
andfloatio.c:parse()
) as it is just another number format like hexadecimal, octal, and binary. Also, doing it that way we can add support for alternative notations (°'"
andhms
, although the latter will probably be confused with the alternative hexadecimal notation by users and reserve one letter keywords). Implementing it using operators sounds hackish to me.I have fixed the build, but I did not intend the sources for building, rather for a code review of the changes.
Looks okay to me, but the math module is not really "my" part.

I give up, I am no longer working on this, as I have no idea how to proceed.

Issue
#689was marked as a duplicate of this issue. 
repo owner Thanks @syrja !

repo owner  changed status to resolved

repo owner Issue
#856was marked as a duplicate of this issue.  Log in to comment
``` Sorry, it isn't a defect, but I don't know how to change it. ```
Reported by `alexandrezabot` on 20080515 15:15:19