New answers tagged

0

There is a problem: IEEE754 defines relational operations and equality in a way that is well-suited to numerical applications. It is not well-suited to sorting and hashing. So if you want to sort an array based on numerical values, or if you want to add numerical values to a set or use them as keys in a dictionary, you either declare that NaN values are not ...


4

Compilers routinely engage in strength reduction. One common example of which is reducing multiples to adds (as adds are typically faster than multiplies). i*2 transformed to i+i is faster on many machines, (and this is sometimes transformed to i<<1 instead). Implicit multiplies commonly happen in for-loops over arrays (whose element size is > 1 ...


5

I would argue that the IEEE behavior is correct. NaNs are not equivalent to one another in any way; they correspond to ill-defined conditions where a numeric answer isn't appropriate. Beyond the performance benefits that come from using IEEE arithmetic that most processors support natively, I think there's a semantic problem with saying that if isnan(x) ...


1

Your expression uses what we call an infix notation, which is the notation commonly used in arithmetical statements. One way of simplyfing parsing such expressions is converting them to Reverse Polish Notation (RPN) which turns them into a stack-based operation, for example your expression would turn into: PUSH numberOfParticipants PUSH creditedtTickets ...



Top 50 recent answers are included