Minutes and seconds

[Former user]

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 2008-05-15 15:13:23

[Former user]

``` Sorry, it isn't a defect, but I don't know how to change it. ```

Reported by `alexandrezabot` on 2008-05-15 15:15:19

[Former user]

``` Hi Alexandre, thanks for the suggestion. ```

Reported by `helder.pereira.correia` on 2008-05-15 15:31:30 - Labels added: Type-Enhancement - Labels removed: Type-Defect

[Former user]

``` 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 2008-11-05 17:11:58

[Former user]

``` @davitofrg: wouldn't a specialized dock widget or whatever to calculate time fit the purpose better? ```

Reported by `helder.pereira.correia` on 2008-11-05 17:19:35

[Former user]

``` 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 2009-02-12 03:45:26

[Former user]

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 2015-06-10 01:29:12

[Pol Welter]

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. ' in 1°23'). Finally we'll have to deal with a lot of new tokens:

• ° or h 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 interpreting a:b simply as an infix notation for a + b/60, it should be super easy to implement. Precedence: lower than addition. Granted, 0:0:30 still takes longer to type than 30", and arguably more than 30/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 and 45.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.

[Pol Welter]

Issue #536 was marked as a duplicate of this issue.

[Pol Welter]

Issue #407 was marked as a duplicate of this issue.

[Ondřej Španěl]

Plus, by interpreting a:b simply as an infix notation for a + b/60, it should be super easy to implement

Unless 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 as a * 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 both a:b:c.d and b:c.d.

With the a + b/60 interpretation the output handling is a bit more difficult. if a is the integral part, how do you choose if you want the fractional part to be written as b:c.d, or b.d? That would need either two separate output formats, or a selector like decimal fractional parts.

[Pol Welter]

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.

[Pol Welter]

In fact, I have an idea how the associativity stuff could be dealt with.

Write a function like bool comparePrecedence(Operator left, Operator right). When left and right are different operators, return true if left has higher precedence than right. If both are the same, return true if the op is left associative. false otherwise.

Could work, right?

[Ondřej Španěl]

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):(20-9).

[Ondřej Španěl]

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.

[Pol Welter]

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

[Pol Welter]

While sexagecial is correct and sounds cool

Imo 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?

[Ondřej Španěl]

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?

[Ondřej Španěl]

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.

[Pol Welter]

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

[Ondřej Španěl]

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).

[Tey']

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() and floatio.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 (°'" and hms, 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.

[Ondřej Španěl]

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

[Pol Welter]

Issue #689 was marked as a duplicate of this issue.

[Helder Correia]

Thanks @syrja !

[Helder Correia]

Issue #856 was marked as a duplicate of this issue.