Can you explain this Excel formula?

Nukumai

tomstickland wrote: »

/8600 is bad practice though - it's a "magic number". Better practice to have "24 * 60"

Again, I fully agree. Expressing this type of calculation verbosely makes the programmer's purpose clear and unambiguous. Having said this, a descriptively-named Constant could also be declared with the requisite explanatory comment.

DVardysShadow

Nukumai wrote: »

Agree 100%. I, too, have worked with developing and using analytical / mathematical software for a good many years (trading and risk management in the banking sector) and would have absolutely no tolerance for a programmer who did not have a full grasp of mathematical operator precedence. There is just no excuse.

In fact, I am astounded at some of what I have read in this thread (eg. the insistence upon parenthesis at academic level).

Astounded you might be. But the situation is industrial, NOT Academic. The software is in large multiprogrammer projects. If I were reviewing your code and you were leaning too heavily on precedence, I am quite confident my management would back me up.

A factor which ameliorates the apparent excess of brackets is good use of multiple lines and of whitespace. We have to teach that and I am afraid to say that there are a few ideas we have to disabuse mathematicians of once they start coding - for example the idea that recursion is more efficient because it uses less memory.

There are very capable programmers out there who are not mathematicians. Review of how they bracket off expressions is a fair way of determining how well they have understood when translating a mathematical statement into code. And a further benefit is that bracketing is a very handy way of demarcating the limits of a dimensionality check.

And of course, as I said before, precedence is far larger than BODMAS, covering several dozens of operators. Code is not mathematics and it is mistaken to pretend that it is.

tomstickland

You can't be mistaken if you're pretending.

Nukumai

I'm not sure what "mathematicians" have to do with it. Knowledge of arithmetic operator precedence is fundamental to coding - just like knowledge of Boolean operands. And these rules are, by and large, simple and universal.

DVardysShadow wrote: »

Astounded you might be. But the situation is industrial, NOT Academic. The software is in large multiprogrammer projects. If I were reviewing your code and you were leaning too heavily on precedence, I am quite confident my management would back me up.

A factor which ameliorates the apparent excess of brackets is good use of multiple lines and of whitespace. We have to teach that and I am afraid to say that there are a few ideas we have to disabuse mathematicians of once they start coding - for example the idea that recursion is more efficient because it uses less memory.

There are very capable programmers out there who are not mathematicians. Review of how they bracket off expressions is a fair way of determining how well they have understood when translating a mathematical statement into code. And a further benefit is that bracketing is a very handy way of demarcating the limits of a dimensionality check.

And of course, as I said before, precedence is far larger than BODMAS, covering several dozens of operators. Code is not mathematics and it is mistaken to pretend that it is.

DVardysShadow

Nukumai wrote: »

I'm not sure what "mathematicians" have to do with it. Knowledge of arithmetic operator precedence is fundamental to coding - just like knowledge of Boolean operands. And these rules are, by and large, simple and universal.

Exactly NOT. You can program quite satisfactorily without a knowledge of precedence. You use brackets and define your own precedence. Precedence is trivial - it is merely a set of defaults on execution order. One of the guidelines for industrial strength coding is not to rely on defaults ...

It might be fundamental to your style of programming. But if it is possible to code correct code without using precedence, then precedence can hardly be described as fundamental.

Nukumai

Darth - in using the term "fundamental knowledge" (of arithmetic operands), I am not inferring that it is not possible to code without it. In fact, I recall that there were (are?) languages out there whose actual order of arithmetic precedence were/are determined sequentially (ie. left -> right / right -> left).

Besides, the mere conscious use of parenthesis to dictate the order of operations, in itself, demonstrates some degree of knowledge about operand precedence on the part of the programmer - however trivial.

What I will say, is that I deem knowledge of arithmetic operands to be taken as a given if I am hiring or utilising a professional coder. And in my experience, this has proved to be a valid assumption on my part.

From my perspective, my attention was caught by a couple of statements you made earlier :

When I teach software, I tell students that there are precedence rules, BUT I do not want them to spend a microsecond learning those rules or ever to use them. (#9)

...and the related part where you said you would "pass x-(100*y), but fail x-100*y" (#13)

I guess we will just have to differ in our perspectives - more knowledgeable people than me have already discussed this with you in other postings.

DVardysShadow wrote: »

Exactly NOT. You can program quite satisfactorily without a knowledge of precedence. You use brackets and define your own precedence. Precedence is trivial - it is merely a set of defaults on execution order. One of the guidelines for industrial strength coding is not to rely on defaults ...

It might be fundamental to your style of programming. But if it is possible to code correct code without using precedence, then precedence can hardly be described as fundamental.

John_Gray

DVardysShadow wrote: »

In the old days of FORTRAN with punched cards, possibly it was better to rely on precedence rather than on disambiguation with brackets.

I'm afraid I do not follow your logic here. People wrote FORTRAN statements so that it was intelligible to them, which meant that specifying brackets reduced the possibility of error. The compiler could handle (mostly!) whatever was thrown at it.

PS I think you win the Thread Prize for the Best Word: disambiguation!

James_cuck

Thanks for sharing these type of problems here

DVardysShadow

Nukumai wrote: »

Darth - in using the term "fundamental knowledge" (of arithmetic operands), I am not inferring that it is not possible to code without it. In fact, I recall that there were (are?) languages out there whose actual order of arithmetic precedence were/are determined sequentially (ie. left -> right / right -> left). [1]

Besides, the mere conscious use of parenthesis to dictate the order of operations, in itself, demonstrates some degree of knowledge about operand precedence on the part of the programmer - however trivial. [2]

What I will say, is that I deem knowledge of arithmetic operands to be taken as a given if I am hiring or utilising a professional coder. And in my experience, this has proved to be a valid assumption on my part. [3]

From my perspective, my attention was caught by a couple of statements you made earlier :

When I teach software, I tell students that there are precedence rules, BUT I do not want them to spend a microsecond learning those rules or ever to use them. (#9)[4]

...and the related part where you said you would "pass x-(100*y), but fail x-100*y" (#13)

I guess we will just have to differ in our perspectives - more knowledgeable people than me have already discussed this with you in other postings.

[1] There is of course, reverse polish notation which is derived from polish notation. There is nothing 'given' about the precedence rules. They are merely a convention - just one way of skinning a cat - and you need to take into account that precedence rules or even the approach to precedence can differ between languages.

Another aspect to this issue is that in preferring 'all brackets', I am stating a preference at one extreme. I am equally happy with reverse polish notation, which is effectively no brackets. In either case, the order of execution is quite explicit. I do have a strong personal dislike for relying on precedence, because it is effectively a hybrid of 'all brackets' and reverse polish - and the order of execution relies upon analysis of the operators themselves - not the case for all brackets or reverse polish.

[2] Agree strongly with this

[3] If I was hiring, I would expect a coder or a specifier to know that there is such a thing as precedence - and where to find the rules. But i would not be bothered whether they could tall me the complete precedence list.

I would hope to find programmers who could cope with languages such as lisp and who might be able to cope with the essentials of assembler. It is far more important to me that the programmer understands the concept and is mentally agile to be able to cope with different approaches than whether he can show off his familiarity with a particular set of precedence rules.

[4] I also tell them how to find the rules.

KimYeovil

Hooray! We want more geek fights on MSE!