A float is a binary fraction, and can not represent most decimal fractions exactly. 0.1 is a famous example of a decimal fraction that can not be represented exactly in binary, just like 1/3 is impossible to represent in decimal (0.333333333333333333333...)
Rational can express many fractions exactly, but as soon as you start working with irrational numbers there is no clear way to do rounding. Rational also have a limited range compared to floating point, so you get overflow (or underflow) much easier. kl. 11:13:06 UTC+2 mandag 9. juni 2014 skrev Stéphane Laurent følgende: > > A Float is a decimal number, hence it also is a rational number : > > *2.243423592592582385923 = 2243423592592582385923 / 1000000000000000000000* > > > Hence, depending on the limitations about the sizes of the integers, the > set Rational could be bigger than the set Float. In this case, the better > approximation of an irrational is achieved by a Rational. > > > > Le lundi 9 juin 2014 02:16:24 UTC+2, Miguel Bazdresch a écrit : >> >> Thanks -- I wasn't aware that a^b is irrational in general in this case. >> Now I wonder if a Float is a better approximation to an irrational number >> than a Rational. >> >> Of course, one could say that sqrt(a) is complex in general for real a, >> but Julia returns a real. As Stefan says, some of these cases have no good >> solutions, only less worse ones. >> >> -- mb >> >> >> On Sun, Jun 8, 2014 at 7:09 PM, 'Stéphane Laurent' via julia-users < >> julia...@googlegroups.com> wrote: >> >>> If b is rational then a^b is irrational in general, even for a integer, >>> so this output is quite expected, as well as >>> >>> julia> (10//1)^(2//1) >>> >>> 100.0 >>> >>> >>> >>> >>> Le lundi 9 juin 2014 00:54:37 UTC+2, Miguel Bazdresch a écrit : >>>> >>>> I just tried this (on 0.2.1): >>>> >>>> julia> (10//1)^(-2//1) >>>> 0.01 >>>> >>>> Is this expected? >>>> >>>> -- mb >>>> >>>> >>>> >>>> On Sun, Jun 8, 2014 at 6:36 PM, 'Stéphane Laurent' via julia-users < >>>> julia...@googlegroups.com> wrote: >>>> >>>>> julia> (10//1)^(-2) >>>>> >>>>> 1//100 >>>>> >>>>> >>>>> Would it be problematic to return a rational >>>>> for (a::Integer)^(b::Integer) ? >>>>> >>>>> >>>>> >>>>> Le dimanche 8 juin 2014 21:53:45 UTC+2, Stefan Karpinski a écrit : >>>>>> >>>>>> There are three obvious options for (a::Integer)^(b::Integer): >>>>>> >>>>>> 1. Always return an integer ⟹ fails for negative b. >>>>>> 2. Always return a float ⟹ a^2 is not the same as a*a. >>>>>> 3. Return float for negative b, integer otherwise ⟹ not >>>>>> type-stable. >>>>>> >>>>>> As you can see, all of these choices are problematic. The first one, >>>>>> which is what we currently do, seems to be the least problematic. One >>>>>> somewhat crazier option that has been proposed is making ^- as in a^-b >>>>>> parse as a different operator and have a^b return an integer for integer >>>>>> arguments but a^-b return a float for integer arguments. This would have >>>>>> the unfortunate effect of making a^-b different from a^(-b). >>>>>> >>>>>> >>>>>> On Sat, Jun 7, 2014 at 12:41 PM, Daniel Jones <daniel...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> I'd definitely be in favor of '^' converting to float, like '/', >>>>>>> having fallen for than recently >>>>>>> <https://github.com/JuliaLang/Color.jl/commit/c3d05dd2b94f0d38b64ef86022accdfec886a673> >>>>>>> . >>>>>>> >>>>>>> On Sat, Jun 7, 2014, at 12:53 AM, Ivar Nesje wrote: >>>>>>> > >>>>>>> > There has also been discussion on whether ^(a::Integer,b::Integer) >>>>>>> should >>>>>>> > return a Float64 by default, and defer to pow() like /(a::Integer, >>>>>>> > b::Integer) defers to div(). The problem is that many people like >>>>>>> the >>>>>>> > 10^45 vs 1e45 notation for large integers vs float constants, and >>>>>>> we can >>>>>>> > make it a clean error instead of a silent bug. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>
