Open barbariand opened 3 months ago
Imperial?!? Honestly I don't think we should have those. Physics is basically always done with metric units, and the meaning of the constants should be metric in my opinion.
I don't think we should add \pm\infty nor NaN as constants. While they may exist in f64:s, mathematically they are not real numbers and shouldn't be something that we represent in Reti like that. In some cases, like if we add sets [0, \infty)
I think that should be handled separately. I also don't think f64 min/max is relevant from a mathematical perspective.
ln(2), \sqrt{2}, \sqrt{3} don't need to be constants, to get them you just have to type what I just did and evaluate the sqrt or ln.
Imperial?!? Honestly I don't think we should have those. Physics is basically always done with metric units, and the meaning of the constants should be metric in my opinion.
I know that they are rarley used in sweden but i think they are used enought from people in usa that it would be worth it as i have macros to make it really easy to convert
I don't think we should add \pm\infty nor NaN as constants. While they may exist in f64:s, mathematically they are not real numbers and shouldn't be something that we represent in Reti like that. In some cases, like if we add sets
[0, \infty)
I think that should be handled separately. I also don't think f64 min/max is relevant from a mathematical perspective.
i can agree with max and min buuut i think infinity is actually nice sometimes, but yea maybe it should be evaluated seperatly
ln(2), \sqrt{2}, \sqrt{3} don't need to be constants, to get them you just have to type what I just did and evaluate the sqrt or ln.
Yea but if we where gonna substitute sin(π)=0 then i think it is ok too have and do that substitution too, remeber that as we are working with presison it is not actually garantied to be the same even during the same run of the program and it would be kinda wierd if it changed. Now ik there needs to be a limit somewhere
It is also not that hard to suport imperial , except maybe in a ui design perspective but even that is not that big of a hurdel
ln(2), \sqrt{2}, \sqrt{3} don't need to be constants, to get them you just have to type what I just did and evaluate the sqrt or ln.
Yea but if we where gonna substitute sin(π)=0 then i think it is ok too have and do that substitution too, remeber that as we are working with presison it is not actually garantied to be the same even during the same run of the program and it would be kinda wierd if it changed. Now ik there needs to be a limit somewhere
Maybe it is there we should draw the line and don't repeat our self, I will sleep on this.
Though if it is a mathident we can maybe do ast magic hmmm
Lol Ive not even thought about it but we need to do conditional ast manipulation depending on what constants are actually correct
Lol Ive not even thought about it but we need to do conditional ast manipulation depending on what constants are actually correct
What do you mean?
If sin is redefined we can not assumme that sin(x)^2+cos(x)^2 =1 or derivatiok and sutch also breaks
I kinda think that constants should be MathExpr
s. So that m_e=9.1\cdot10^{-31}
. Because with the correct setup in the constants
branch I don't even think f64:s can support such small numbers, so it might just be equal to zero.
Long term I also kind of want all our evaluations to be handled in simplification, with infinite prediction using fractions and constants. Only when approximating would we be forced to used f64:s or similar.
Yea ok that is actually a better idea tbh
While American users might want to think about the speed of light in imperial units, the constant c
is associated with the value 299 ... in meters/second. You can measure the speed of light in miles/s if you want, but the constant c, that's still a constant in meters/second.
If we want to support imperial units I would rather see a proper units system where you can change units on the result, so all calculations could be in SI units and the result is "32 m/s", and when pressing a button to change units it will translate the value to "10 feet/s" or whatever is relevant. But I also think this is hard and may be error-prone. So if implemented it should be done in the future in my opinion.
So pi and sutch are not used untill approximating
While American users might want to think about the speed of light in imperial units, the constant
c
is associated with the value 299 ... in meters/second. You can measure the speed of light in miles/s if you want, but the constant c, that's still a constant in meters/second.If we want to support imperial units I would rather see a proper units system where you can change units on the result, so all calculations could be in SI units and the result is "32 m/s", and when pressing a button to change units it will translate the value to "10 feet/s" or whatever is relevant. But I also think this is hard and may be error-prone. So if implemented it should be done in the future in my opinion.
I'd rather see us have this than the constants but if we do actually unit calculation I think it should be removed and that everything should flow through the SI system. But to be clear I don't need to keep the Imperial i just slightly think we should
The pros outwey the cons from how I see it for having imperial constants that are pre converted when we can't but ig you could do it lanualy
So pi and sutch [sic] are not used untill [sic] approximating
Yes exactly. Just like a mathematician would prefer to answer =2\pi/3+\sqrt{2}
instead of /approx8.2...
I think Reti should do the same
And that makes it easier to do complex numbers too huh
Tracking issue for all numerical constants that are planned or added to Reti as of the date of the latest update. This issue is not to be closed and if you want to add more please refrence this tracking issue
[x] f64limitations
[ ] Mathematical constants
[ ] Physics SI Units
[ ] Physics Imperial Units
[ ] Chem
If there is any more that are needed then i can add them here to the list