Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't understand how this is supposed to work. For one thing iterative code wouldn't even do the same number of iterations when you change the desired precision, so merely plugging in higher precision numbers wouldn't give the higher precision approximation you'd be looking for. You'd have to actually re-execute the entire code with higher precision numbers so that intermediate control flow decisions use those numbers instead too, right?


If you made decisions based off of precision at some point in time, then you’re right. You’ve “baked” into the number some aspect about a precision decision you’ve previously made. That doesn’t invalidate the number, as it reflects precisely the number you asked for, it just means you’re expressing your computation in a dubious manner.

Sometimes it’s unavoidable though, such as when checking equality where you have to call it quits at some point at some precision.


Generally, precision is pulled on-demand, as it is needed. If you compare two values as x < y, x and y will be evaluated to higher and higher precision until the answer is unambiguous. This can be an issue if the values are equal, since they often cannot be proven to be equal, so the evaluation may just outright fail to terminate.


That doesn't address the situation I outlined?


You store the expression. Because that expression is a computable real, you can calculate it to arbitrary precision.

This is quite inefficient for things like summing over a list. Or really, any kind of accumulation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: