4 ms·

Maintaining symbolic values could quickly blow up. For example when using iterative methods. Are you aware of any languages doing symbolic representation with s

by lolc 7y ago

Maintaining symbolic values could quickly blow up. For example when using iterative methods. Are you aware of any languages doing symbolic representation with standard types? I don't see how irrationals as floats is premature optimization. If you already know symbolic representation is going to blow up quickly and cause downstream headaches the measures you take are not premature. Though now I do wonder how the headaches stack up against the float headaches :-) Don't get me wrong I like the idea of symbolic representation. It's just that in everyday use it seems very impractical to me. Granted, limited forms of it like the fractional type don't have the complexity problem. But in many cases things devolve to floats quickly anyway. The people that care can use libraries and deal with the complexity.

ivanbakel 7y ago
"could" is the operative word. How many programs do enough calculation to make the tradeoffs of floats worthwhile? Conversely, how many programs need correctness more, and get caught out by float gotcha? This is the definition of premature optimisation - not knowing the impact, you're suggesting a performance change anyways. The point is, for programmers that don't care, inefficiency is good enough.
dragonwriter 7y ago
> Maintaining symbolic values could quickly blow up. It could, in certain circumstances. > I don't see how irrationals as floats is premature optimization. It is, when it is because “could” and not because “does”. > If you already know symbolic representation is going to blow up quickly and cause downstream headaches the measures you take are not premature Sure, if you know that's going to happen. When you do it because it might happen, or because it happens to be the language’s default representation of irrational (or even exact decimal, or in JS’s case exact integer) numbers, that's a different story.
- lolc 7y ago
  So can you name a language that does symbolic representation? It sounds like one of those things which are great in theory but hellish in implementation.

by lolc 7y ago

ivanbakel 7y ago

"could" is the operative word. How many programs do enough calculation to make the tradeoffs of floats worthwhile? Conversely, how many programs need correctness more, and get caught out by float gotcha? This is the definition of premature optimisation - not knowing the impact, you're suggesting a performance change anyways. The point is, for programmers that don't care, inefficiency is good enough.

dragonwriter 7y ago

> Maintaining symbolic values could quickly blow up. It could, in certain circumstances. > I don't see how irrationals as floats is premature optimization. It is, when it is because “could” and not because “does”. > If you already know symbolic representation is going to blow up quickly and cause downstream headaches the measures you take are not premature Sure, if you know that's going to happen. When you do it because it might happen, or because it happens to be the language’s default representation of irrational (or even exact decimal, or in JS’s case exact integer) numbers, that's a different story.

lolc 7y ago
So can you name a language that does symbolic representation? It sounds like one of those things which are great in theory but hellish in implementation.