Re: [julia-users] How Julia do math operations
Well, I'm not sure what the intention was, but this fact is true: for floating-point values x and y of the same type, x == y is true if and only if string(x) == string(y). On Wed, Nov 5, 2014 at 5:36 AM, Steven G. Johnson stevenj@gmail.com wrote: On Tuesday, November 4, 2014 8:44:55 PM UTC-5, Stefan Karpinski wrote: The == check works exactly the same way in Julia as it does in other languages. It's the printing of the numbers that's more precise. Maybe K. Leo was asking whether Julia always prints out enough decimal digits from x::Float64 to guarantee that the original floating-point value x will be reconstructed from this decimal literal. I think the answer is yes?
Re: [julia-users] How Julia do math operations
On Wed, Nov 5, 2014 at 2:48 AM, Jameson Nash vtjn...@gmail.com wrote: fun fact: even with format long, matlab doesn't always print enough digits to reconstruct the number Do you have an example? If true, this is rather horrifying. Is there simply no way to print a true value from Matlab then?
Re: [julia-users] How Julia do math operations
The matlab docs clearly specifies format long as 15 digits http://www.mathworks.se/help/matlab/matlab_prog/display-format-for-numeric-values.html. Julia usually prints 16 (or 17) digits for a call to rand(). This is a typical distribution of the number of digits from a `rand(1_000_000)` call (eg, length(x)-2, to remove the 0. prefix) 10 1 11 12 12 67 13 624 146708 15 66337 16 610505 17 282185 18 30420 192944 20 197 This (probably) means that most often Matlab prints a number that can't be parsed back to the same number. Code in gist https://gist.github.com/ivarne/fe258ea95b9982827676 Ivar kl. 11:25:16 UTC+1 onsdag 5. november 2014 skrev Stefan Karpinski følgende: On Wed, Nov 5, 2014 at 2:48 AM, Jameson Nash vtj...@gmail.com javascript: wrote: fun fact: even with format long, matlab doesn't always print enough digits to reconstruct the number Do you have an example? If true, this is rather horrifying. Is there simply no way to print a true value from Matlab then?
Re: [julia-users] How Julia do math operations
You may want to check the isapprox function.
Re: [julia-users] How Julia do math operations
IMO simulation is not necessary here --- double float is known to have 52 bits for the significand, so which tranlates to a bit less than 16 decimal digits, + 1 for rounding error (magnitude of rounding error is non-uniform when reading back from decimal), which is how you get 17, so clearly 15 is not enough. On Wed, Nov 05 2014, Ivar Nesje iva...@gmail.com wrote: The matlab docs clearly specifies format long as 15 digits http://www.mathworks.se/help/matlab/matlab_prog/display-format-for-numeric-values.html. Julia usually prints 16 (or 17) digits for a call to rand(). This is a typical distribution of the number of digits from a `rand(1_000_000)` call (eg, length(x)-2, to remove the 0. prefix) 10 1 11 12 12 67 13 624 146708 15 66337 16 610505 17 282185 18 30420 192944 20 197 This (probably) means that most often Matlab prints a number that can't be parsed back to the same number. Code in gist https://gist.github.com/ivarne/fe258ea95b9982827676 Ivar kl. 11:25:16 UTC+1 onsdag 5. november 2014 skrev Stefan Karpinski følgende: On Wed, Nov 5, 2014 at 2:48 AM, Jameson Nash vtj...@gmail.com javascript: wrote: fun fact: even with format long, matlab doesn't always print enough digits to reconstruct the number Do you have an example? If true, this is rather horrifying. Is there simply no way to print a true value from Matlab then?
Re: [julia-users] How Julia do math operations
I couldn't resist this after my cholfact() revelation...
On Wednesday, November 5, 2014 11:23:03 AM UTC+1, Stefan Karpinski wrote:
Well, I'm not sure what the intention was, but this fact is true: for
floating-point values x and y of the same type, x == y is true if and only
if string(x) == string(y).
julia a = inv(eye(2))
2x2 Array{Float64,2}:
1.0 -0.0
0.0 1.0
julia a[1,2] == a[2,1]
true
julia string(a[1,2]) == string(a[2,1])
false
(pardon the formatting, I don't seem to have a good handle on this in
google groups)
Cheers,
---david
Re: [julia-users] How Julia do math operations
This code prints a random Float64 that requires more than 15 digits to
reconstruct:
while true
x = rand()
if parsefloat(@sprintf(%.15f, x)) != x
println(x)
break
end
end
There are lots of them. What's more surprising is that if you replace 15
with anything up to 20, it still returns really quickly – at 21 it hangs.
This implies that values requiring up to 20 digits to print honestly are
quite common.
On Wed, Nov 5, 2014 at 1:53 PM, David van Leeuwen
david.vanleeu...@gmail.com wrote:
I couldn't resist this after my cholfact() revelation...
On Wednesday, November 5, 2014 11:23:03 AM UTC+1, Stefan Karpinski wrote:
Well, I'm not sure what the intention was, but this fact is true: for
floating-point values x and y of the same type, x == y is true if and only
if string(x) == string(y).
julia a = inv(eye(2))
2x2 Array{Float64,2}:
1.0 -0.0
0.0 1.0
julia a[1,2] == a[2,1]
true
julia string(a[1,2]) == string(a[2,1])
false
(pardon the formatting, I don't seem to have a good handle on this in
google groups)
Cheers,
---david
Re: [julia-users] How Julia do math operations
On Wednesday, November 5, 2014 4:25:16 AM UTC-6, Stefan Karpinski wrote: On Wed, Nov 5, 2014 at 2:48 AM, Jameson Nash vtjn...@gmail.com wrote: fun fact: even with format long, matlab doesn't always print enough digits to reconstruct the number Do you have an example? If true, this is rather horrifying. Is there simply no way to print a true value from Matlab then? format hex (which I learned from Dr. Edelman, either in an issue or on this mailing list)
Re: [julia-users] How Julia do math operations
I think that you are just running floats which are subnormal in a
fixed-point decimal representation: with %.17f, they have (on average)
a single 0 after the decimal dot, with %.18f, they have two,
etc. Printing them with %f but a fixed number of digits is not the right
way, since you waste digits on these zeroes.
It should not hang at 21, except, of course, it will
take more time to generate a float below approx 1e-5.
David's issue is different, and essentially boils down to
julia bits(1/Inf)
julia bits(-1/Inf)
1000
which are equal when compared with == (which follows the IEEE standard)
but not is(,) (which compares bits).
Best,
Tamas
On Wed, Nov 05 2014, Stefan Karpinski ste...@karpinski.org wrote:
This code prints a random Float64 that requires more than 15 digits to
reconstruct:
while true
x = rand()
if parsefloat(@sprintf(%.15f, x)) != x
println(x)
break
end
end
There are lots of them. What's more surprising is that if you replace 15
with anything up to 20, it still returns really quickly – at 21 it hangs.
This implies that values requiring up to 20 digits to print honestly are
quite common.
On Wed, Nov 5, 2014 at 1:53 PM, David van Leeuwen
david.vanleeu...@gmail.com wrote:
I couldn't resist this after my cholfact() revelation...
On Wednesday, November 5, 2014 11:23:03 AM UTC+1, Stefan Karpinski wrote:
Well, I'm not sure what the intention was, but this fact is true: for
floating-point values x and y of the same type, x == y is true if and only
if string(x) == string(y).
julia a = inv(eye(2))
2x2 Array{Float64,2}:
1.0 -0.0
0.0 1.0
julia a[1,2] == a[2,1]
true
julia string(a[1,2]) == string(a[2,1])
false
(pardon the formatting, I don't seem to have a good handle on this in
google groups)
Cheers,
---david
Re: [julia-users] How Julia do math operations
No, these aren't subnormal values, although they are small. Using %.16e
does print them all accurately though, so that's a bit misleading. By
hang I meant that it doesn't return quickly, not that it won't ever
return.
On Wed, Nov 5, 2014 at 2:27 PM, Tamas Papp tkp...@gmail.com wrote:
I think that you are just running floats which are subnormal in a
fixed-point decimal representation: with %.17f, they have (on average)
a single 0 after the decimal dot, with %.18f, they have two,
etc. Printing them with %f but a fixed number of digits is not the right
way, since you waste digits on these zeroes.
It should not hang at 21, except, of course, it will
take more time to generate a float below approx 1e-5.
David's issue is different, and essentially boils down to
julia bits(1/Inf)
julia bits(-1/Inf)
1000
which are equal when compared with == (which follows the IEEE standard)
but not is(,) (which compares bits).
Best,
Tamas
On Wed, Nov 05 2014, Stefan Karpinski ste...@karpinski.org wrote:
This code prints a random Float64 that requires more than 15 digits to
reconstruct:
while true
x = rand()
if parsefloat(@sprintf(%.15f, x)) != x
println(x)
break
end
end
There are lots of them. What's more surprising is that if you replace 15
with anything up to 20, it still returns really quickly – at 21 it hangs.
This implies that values requiring up to 20 digits to print honestly
are
quite common.
On Wed, Nov 5, 2014 at 1:53 PM, David van Leeuwen
david.vanleeu...@gmail.com wrote:
I couldn't resist this after my cholfact() revelation...
On Wednesday, November 5, 2014 11:23:03 AM UTC+1, Stefan Karpinski
wrote:
Well, I'm not sure what the intention was, but this fact is true: for
floating-point values x and y of the same type, x == y is true if and
only
if string(x) == string(y).
julia a = inv(eye(2))
2x2 Array{Float64,2}:
1.0 -0.0
0.0 1.0
julia a[1,2] == a[2,1]
true
julia string(a[1,2]) == string(a[2,1])
false
(pardon the formatting, I don't seem to have a good handle on this in
google groups)
Cheers,
---david
[julia-users] How Julia do math operations
julia f(x::Float64, y::Float64) = 2x + y; julia f(10.97,23.9985) 45.9385005 The above method execution of function f returns an answer that I cannot understand. Can someone clarify? Thank you.
Re: [julia-users] How Julia do math operations
Hi Neil, Julie does math the same way that all computers do math. You're probably coming from another language where a lot of effort is invested into pretending that computers offer a closer approximation to abstract mathematics than they actually do. Those systems have been lying to you. Put another way: you just took the red pill by using Julia. -- John On Nov 4, 2014, at 11:06 AM, Neil Devadasan ndeva...@gmail.com wrote: julia f(x::Float64, y::Float64) = 2x + y; julia f(10.97,23.9985) 45.9385005 The above method execution of function f returns an answer that I cannot understand. Can someone clarify? Thank you.
Re: [julia-users] How Julia do math operations
Thanks On Tuesday, November 4, 2014 2:13:37 PM UTC-5, John Myles White wrote: Hi Neil, Julie does math the same way that all computers do math. You're probably coming from another language where a lot of effort is invested into pretending that computers offer a closer approximation to abstract mathematics than they actually do. Those systems have been lying to you. Put another way: you just took the red pill by using Julia. -- John On Nov 4, 2014, at 11:06 AM, Neil Devadasan ndev...@gmail.com javascript: wrote: julia f(x::Float64, y::Float64) = 2x + y; julia f(10.97,23.9985) 45.9385005 The above method execution of function f returns an answer that I cannot understand. Can someone clarify? Thank you.
Re: [julia-users] How Julia do math operations
Some systems round their answers as John said but it's easy to check that it's a lie: R version 3.1.0 (2014-04-10) -- Spring Dance 2*10.97 + 23.9985 [1] 45.9385 2*10.97 + 23.9985 == 45.9385 [1] FALSE This is perl 5, version 16, subversion 2 (v5.16.2) DB1 x 2*10.97 + 23.9985 0 45.9385 DB2 x 2*10.97 + 23.9985 == 45.9385 0 '' I don't have a working copy of Matlab right now, but I think it does this too. On Tue, Nov 4, 2014 at 8:31 PM, Neil Devadasan ndeva...@gmail.com wrote: Thanks On Tuesday, November 4, 2014 2:13:37 PM UTC-5, John Myles White wrote: Hi Neil, Julie does math the same way that all computers do math. You're probably coming from another language where a lot of effort is invested into pretending that computers offer a closer approximation to abstract mathematics than they actually do. Those systems have been lying to you. Put another way: you just took the red pill by using Julia. -- John On Nov 4, 2014, at 11:06 AM, Neil Devadasan ndev...@gmail.com wrote: julia f(x::Float64, y::Float64) = 2x + y; julia f(10.97,23.9985) 45.9385005 The above method execution of function f returns an answer that I cannot understand. Can someone clarify? Thank you.
Re: [julia-users] How Julia do math operations
On Matlab R2013b: 2*10.97 + 23.9985 ans = 45.9385 2*10.97 + 23.9985 == 45.9385 ans = 0 -- mb On Tue, Nov 4, 2014 at 7:48 PM, Stefan Karpinski ste...@karpinski.org wrote: Some systems round their answers as John said but it's easy to check that it's a lie: R version 3.1.0 (2014-04-10) -- Spring Dance 2*10.97 + 23.9985 [1] 45.9385 2*10.97 + 23.9985 == 45.9385 [1] FALSE This is perl 5, version 16, subversion 2 (v5.16.2) DB1 x 2*10.97 + 23.9985 0 45.9385 DB2 x 2*10.97 + 23.9985 == 45.9385 0 '' I don't have a working copy of Matlab right now, but I think it does this too. On Tue, Nov 4, 2014 at 8:31 PM, Neil Devadasan ndeva...@gmail.com wrote: Thanks On Tuesday, November 4, 2014 2:13:37 PM UTC-5, John Myles White wrote: Hi Neil, Julie does math the same way that all computers do math. You're probably coming from another language where a lot of effort is invested into pretending that computers offer a closer approximation to abstract mathematics than they actually do. Those systems have been lying to you. Put another way: you just took the red pill by using Julia. -- John On Nov 4, 2014, at 11:06 AM, Neil Devadasan ndev...@gmail.com wrote: julia f(x::Float64, y::Float64) = 2x + y; julia f(10.97,23.9985) 45.9385005 The above method execution of function f returns an answer that I cannot understand. Can someone clarify? Thank you.
Re: [julia-users] How Julia do math operations
julia 2*10.97 + 23.9985 45.9385005 julia 2*10.97 + 23.9985 == 45.9385005 true Amazing. I never expected this. Is floating point comparison going to be guaranteed? On 2014年11月05日 08:48, Stefan Karpinski wrote: Some systems round their answers as John said but it's easy to check that it's a lie: R version 3.1.0 (2014-04-10) -- Spring Dance 2*10.97 + 23.9985 [1] 45.9385 2*10.97 + 23.9985 == 45.9385 [1] FALSE This is perl 5, version 16, subversion 2 (v5.16.2) DB1 x 2*10.97 + 23.9985 0 45.9385 DB2 x 2*10.97 + 23.9985 == 45.9385 0 '' I don't have a working copy of Matlab right now, but I think it does this too. On Tue, Nov 4, 2014 at 8:31 PM, Neil Devadasan ndeva...@gmail.com mailto:ndeva...@gmail.com wrote: Thanks On Tuesday, November 4, 2014 2:13:37 PM UTC-5, John Myles White wrote: Hi Neil, Julie does math the same way that all computers do math. You're probably coming from another language where a lot of effort is invested into pretending that computers offer a closer approximation to abstract mathematics than they actually do. Those systems have been lying to you. Put another way: you just took the red pill by using Julia. -- John On Nov 4, 2014, at 11:06 AM, Neil Devadasan ndev...@gmail.com wrote: julia f(x::Float64, y::Float64) = 2x + y; julia f(10.97,23.9985) 45.9385005 The above method execution of function f returns an answer that I cannot understand. Can someone clarify? Thank you.
Re: [julia-users] How Julia do math operations
On Wed, Nov 5, 2014 at 2:06 AM, K Leo cnbiz...@gmail.com wrote: julia 2*10.97 + 23.9985 45.9385005 julia 2*10.97 + 23.9985 == 45.9385005 true Amazing. I never expected this. Is floating point comparison going to be guaranteed? What's shocking about this? What do you mean by floating point comparison being guaranteed? We always print individual floating-point numbers with enough digits to reconstruct their exact value (moreover, they are always printed with the minimal number of digits necessary to do so). Floating-point arrays are printed truncated.
Re: [julia-users] How Julia do math operations
Don't know what you mean by guaranteeing a floating point comparison. In any event, you should never check equality when comparing floating point numbers (except perhaps in special cases). Instead, use a tolerance: tol = 1e-12; if (abs(a-b) tol) # Close enough else # not equal end The problems you see in other languages are due to the fact they round the values they display (but the underlying values are not rounded). The return you got from Juila was not rounded for display. Stuart On Wed, 5 Nov 2014, K Leo wrote: julia 2*10.97 + 23.9985 45.9385005 julia 2*10.97 + 23.9985 == 45.9385005 true Amazing. I never expected this. Is floating point comparison going to be guaranteed? On 2014?11?05? 08:48, Stefan Karpinski wrote: Some systems round their answers as John said but it's easy to check that it's a lie: R version 3.1.0 (2014-04-10) -- Spring Dance 2*10.97 + 23.9985 [1] 45.9385 2*10.97 + 23.9985 == 45.9385 [1] FALSE This is perl 5, version 16, subversion 2 (v5.16.2) DB1 x 2*10.97 + 23.9985 0 45.9385 DB2 x 2*10.97 + 23.9985 == 45.9385 0 '' I don't have a working copy of Matlab right now, but I think it does this too. On Tue, Nov 4, 2014 at 8:31 PM, Neil Devadasan ndeva...@gmail.com mailto:ndeva...@gmail.com wrote: Thanks On Tuesday, November 4, 2014 2:13:37 PM UTC-5, John Myles White wrote: Hi Neil, Julie does math the same way that all computers do math. You're probably coming from another language where a lot of effort is invested into pretending that computers offer a closer approximation to abstract mathematics than they actually do. Those systems have been lying to you. Put another way: you just took the red pill by using Julia. -- John On Nov 4, 2014, at 11:06 AM, Neil Devadasan ndev...@gmail.com wrote: julia f(x::Float64, y::Float64) = 2x + y; julia f(10.97,23.9985) 45.9385005 The above method execution of function f returns an answer that I cannot understand. Can someone clarify? Thank you.
Re: [julia-users] How Julia do math operations
Just to follow up on this topic, here's what Matlab does: 2*10.97 + 23.9985 ans = 45.9385 2*10.97 + 23.9985 == 45.9385 ans = 0 format long 2*10.97 + 23.9985 ans = 45.9385005 2*10.97 + 23.9985 == 45.9385005 ans = 1 Note that Matlab's display value is 45.9385, but the actual result is 45.9385005. You only see the display value if you set the display to show all digits (format long) Stuart On Wed, 5 Nov 2014, K Leo wrote: julia 2*10.97 + 23.9985 45.9385005 julia 2*10.97 + 23.9985 == 45.9385005 true Amazing. I never expected this. Is floating point comparison going to be guaranteed? On 2014?11?05? 08:48, Stefan Karpinski wrote: Some systems round their answers as John said but it's easy to check that it's a lie: R version 3.1.0 (2014-04-10) -- Spring Dance 2*10.97 + 23.9985 [1] 45.9385 2*10.97 + 23.9985 == 45.9385 [1] FALSE This is perl 5, version 16, subversion 2 (v5.16.2) DB1 x 2*10.97 + 23.9985 0 45.9385 DB2 x 2*10.97 + 23.9985 == 45.9385 0 '' I don't have a working copy of Matlab right now, but I think it does this too. On Tue, Nov 4, 2014 at 8:31 PM, Neil Devadasan ndeva...@gmail.com mailto:ndeva...@gmail.com wrote: Thanks On Tuesday, November 4, 2014 2:13:37 PM UTC-5, John Myles White wrote: Hi Neil, Julie does math the same way that all computers do math. You're probably coming from another language where a lot of effort is invested into pretending that computers offer a closer approximation to abstract mathematics than they actually do. Those systems have been lying to you. Put another way: you just took the red pill by using Julia. -- John On Nov 4, 2014, at 11:06 AM, Neil Devadasan ndev...@gmail.com wrote: julia f(x::Float64, y::Float64) = 2x + y; julia f(10.97,23.9985) 45.9385005 The above method execution of function f returns an answer that I cannot understand. Can someone clarify? Thank you.
Re: [julia-users] How Julia do math operations
I meant this: to check whether 2 floating point valuables equal I had always had to do something like abs(x-y)1.e-5 (never simply x==y) in other languages. I wonder whether checking x==y would be sufficient in Julia? On 2014年11月05日 09:30, Stefan Karpinski wrote: On Wed, Nov 5, 2014 at 2:06 AM, K Leo cnbiz...@gmail.com mailto:cnbiz...@gmail.com wrote: julia 2*10.97 + 23.9985 45.9385005 julia 2*10.97 + 23.9985 == 45.9385005 true Amazing. I never expected this. Is floating point comparison going to be guaranteed? What's shocking about this? What do you mean by floating point comparison being guaranteed? We always print individual floating-point numbers with enough digits to reconstruct their exact value (moreover, they are always printed with the minimal number of digits necessary to do so). Floating-point arrays are printed truncated.
Re: [julia-users] How Julia do math operations
The == check works exactly the same way in Julia as it does in other languages. It's the printing of the numbers that's more precise. On Wed, Nov 5, 2014 at 2:41 AM, K Leo cnbiz...@gmail.com wrote: I meant this: to check whether 2 floating point valuables equal I had always had to do something like abs(x-y)1.e-5 (never simply x==y) in other languages. I wonder whether checking x==y would be sufficient in Julia? On 2014年11月05日 09:30, Stefan Karpinski wrote: On Wed, Nov 5, 2014 at 2:06 AM, K Leo cnbiz...@gmail.com mailto: cnbiz...@gmail.com wrote: julia 2*10.97 + 23.9985 45.9385005 julia 2*10.97 + 23.9985 == 45.9385005 true Amazing. I never expected this. Is floating point comparison going to be guaranteed? What's shocking about this? What do you mean by floating point comparison being guaranteed? We always print individual floating-point numbers with enough digits to reconstruct their exact value (moreover, they are always printed with the minimal number of digits necessary to do so). Floating-point arrays are printed truncated.
Re: [julia-users] How Julia do math operations
On Tuesday, November 4, 2014 8:42:02 PM UTC-5, K leo wrote: I meant this: to check whether 2 floating point valuables equal I had always had to do something like abs(x-y)1.e-5 (never simply x==y) in other languages. I wonder whether checking x==y would be sufficient in Julia? It depends on what you want. A quick floating-point tutorial seems to be in order here: Each floating-point value is not a real number with uncertainty or random fuzz or an interval. It is just *a rational number.* The floating-point numbers F are a specific subset of the rationals (plus oddballs like ∞ and NaN). *==* simply compares whether two floating-point values are the same rational number. If that is what you want, great! However, because F is only a *subset* of the rationals, various operations incur a roundoff error. This includes conversion from a string to a floating-point value (for binary floating point, F does not include decimal fractions like 0.1, so they are rounded to the nearest value in F, in this case to 0.15551115). It also includes operations like x + y: if the result is in F, it is *exact*, but otherwise the results of binary operations +/–/*/÷ are rounded to the nearest element of F (this is *exact rounding*).And when you do many such operations (e.g. factorizing a matrix), the roundoff errors typically *accumulate*, so the final result can be very far from the exactly rounded answer. (A disturbing number of people think that x * 0 != 0 in floating point [ignoring Inf/NaN], or that 1.0 + 1.0 != 2.0 in floating point. Since these quantities are represented exactly in F, the computations are exact.) As a result, if you are comparing two floating point numbers that are the result of long calculations, which would be exactly equal in exact arithmetic, you typically check whether the relative difference is small: |x–y| ε|x|, where ε is some estimate of the relative accuracy you hope to attain. --SGJ
Re: [julia-users] How Julia do math operations
On Tuesday, November 4, 2014 8:44:55 PM UTC-5, Stefan Karpinski wrote: The == check works exactly the same way in Julia as it does in other languages. It's the printing of the numbers that's more precise. Maybe K. Leo was asking whether Julia always prints out enough decimal digits from x::Float64 to guarantee that the original floating-point value x will be reconstructed from this decimal literal. I think the answer is yes?
