Hacker News new | past | comments | ask | show | jobs | submit login

So you think that the imprecision of saying "O(n)" when the "large-ish" behavior is not relevant is worse than the verbosity of saying "scales directly/with the square of/not-at-all with [relevant constraint]"?

FWIW, Big-O itself, even in technical contexts, gets imprecise with e.g. calling hashtables O(1), which is not possible, even under the idealized computer model (instant memory access, etc).

Is there a shorter way of saying "scales proportionally with n" that you would suggest the tech community prefer because of its greater precision?




But you can't just say "O(n)," you have to specify what n is - at which point it is no longer any more terse than the English alternative.

> What we ended up with was O(n) _classes_ (where n = the number of computation operations).

vs.

> what we ended up with was several classes for each operation.

The second is shorter, and says no more than what is relevant.


That's like saying there's no point in using pronouns, since you have to say the antecedent anyway.

It would be wrong in both cases because the context can make clear what a variable or pronoun refers to. If the problem context makes clear what the binding constraint is and you just need to talk about scaling behavior, then it is indeed shorter to say "O(1) rather than O(n)" vs "doesn't depend on the operations rather than being directly proportional".

>>what we ended up with was several classes for each operation.

>The second is shorter, and says no more than what is relevant.

It says less: the O notation is used to indicate that as you add more operations, you will need to add more classes, rather than only needing to add classes when there is logic the operations don't yet implement.




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

Search: