7 ms·

It gets promoted to a fractional type.

by egdod 7y ago

lolc 7y ago
Ok, what would happen if one then multiplies by Math.PI?
- mafuy 7y ago
  int times float results in float. No problem, is it?
  - lolc 7y ago
    Well it's a fractional type. How do fractional types behave with floats?
- dragonwriter 7y ago
  Ideally, to maintain maximal correctness, it would be in a symbolic representation until an inexact rendering was called for, but simply resorting to floats for irrationals is not entirely unreasonable though it's still a premature optimization, but not as bad as resorting to it for rationals.
  - 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.
- rini17 7y ago
  In sane languages like Common Lisp this works since 90's if not earlier: * (/ 1 3) 1/3 ; result is a fraction * PI 3.141592653589793d0 * (* 1/3 pi) 1.0471975511965976d0 ; fraction * fp -> fp * 9999999999999999999999 9999999999999999999999 ;transparent support for bigints

It gets promoted to a fractional type.

by egdod 7y ago

It gets promoted to a fractional type.

lolc 7y ago

Ok, what would happen if one then multiplies by Math.PI?

mafuy 7y ago
int times float results in float. No problem, is it?
- lolc 7y ago
  Well it's a fractional type. How do fractional types behave with floats?
dragonwriter 7y ago
Ideally, to maintain maximal correctness, it would be in a symbolic representation until an inexact rendering was called for, but simply resorting to floats for irrationals is not entirely unreasonable though it's still a premature optimization, but not as bad as resorting to it for rationals.
- 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.
rini17 7y ago
In sane languages like Common Lisp this works since 90's if not earlier: * (/ 1 3) 1/3 ; result is a fraction * PI 3.141592653589793d0 * (* 1/3 pi) 1.0471975511965976d0 ; fraction * fp -> fp * 9999999999999999999999 9999999999999999999999 ;transparent support for bigints