Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Correctness and composability bugs in the Julia ecosystem

yuri.is

Post reply on HN
Print view View original

411–419 of 419 posts

Re: Correctness and composability bugs in the Julia ecosystem

#411

Post by CRConrad »

CRConrad wrote: post #300
FabHK wrote: post #292

Earlier quoted context omitted.

I thought you'd be wrong, and immediately came up with: - Hours after midnight. The (non-anglosaxon) watch goes from 0:00 to 24:00 (the latter is useful for deadlines: The proposal must be submitted by Friday, 24:00 (which coincides with Saturday, 0:00)). Then I cheated and looked up Wikipedia ( https://en.wikipedia.org/wiki/Zero-based_numbering#Other_fie... ) - and whoops, that's basically it!

Yeah, duh, totally forgot that one. And I should know; the alarm clock on my windowsill says 0:54 right now.

Year -- or rather, decade, century, and millennium -- numbering. We're only in the second year of the second decade of the twenty-first century, so the decade will end and the next start at the end, not the beginning, of 2030.

But this is perhaps more of a problem with numbers and zeroes, and ends and beginnings; people don't get that 10 is the last of the 00s, not the first of the 10s. The very first year was numbered 1, not 0, so that's not the problem. Or, it kind of is: People would be right, if the first year had been 0.

Re: Correctness and composability bugs in the Julia ecosystem

#412

Post by mbauman »

Sporktacular wrote: post #384
adgjlsfhk1 wrote: post #151

Earlier quoted context omitted.

sample size of 1, but I've run 1 billion tests today in Julia (floating point power for Float16, Float32 and Float64)

For correctness? What was the result?

Knowing adgjlsfhk1's work, yes, this would be for correctness — specifically measuring error in ULPs. Most frequently, adgjlsfhk1 pushes Julia's numeric routines to errors below 0.5 ULPs — that is, perfect correctly rounded behavior.

Re: Correctness and composability bugs in the Julia ecosystem

#413

Post by adgjlsfhk1 »

mbauman wrote: post #412
Sporktacular wrote: post #384

Earlier quoted context omitted.

For correctness? What was the result?

Knowing adgjlsfhk1's work, yes, this would be for correctness — specifically measuring error in ULPs. Most frequently, adgjlsfhk1 pushes Julia's numeric routines to errors below 0.5 ULPs — that is, perfect correctly rounded behavior.

I actually am not a believer in perfect rounding. It tends to have a high performance cost, and IMO isn't that useful.

Re: Correctness and composability bugs in the Julia ecosystem

#414

Post by adgjlsfhk1 »

Sporktacular wrote: post #384
adgjlsfhk1 wrote: post #151

Earlier quoted context omitted.

sample size of 1, but I've run 1 billion tests today in Julia (floating point power for Float16, Float32 and Float64)

For correctness? What was the result?

Up until a few days ago, we were testing that x^y was accurate to 1.3 ULPs for Float16, Float32, and Float64. However, for Float16 and Float32, we were actually accurate to (at least) .51 ULP, and Float64 was accurate to 1 ULP so I made the tests stricter there. There are 2 exceptions to this: x^3 and x^-2. because people from a math background often write code with literal powers, and expect it to be fast, for small integer powers (-2, -1, 0, 1, 2, and 3) that are constant, Julia will replace the call to pow with a call to (for example) xxx for x^3. As such, the accuracy bound for x^3 is 1.5 ULP and the bound for x^-2 is 2 ULP for all data types.

This fixed a rare test failure on CI (since for ^3 and ^-2 the bounds were too tight the previous test would fail roughly 1/1000 runs), and will prevent regressions in accuracy if I ever come back to try to make the implementation faster.

Re: Correctness and composability bugs in the Julia ecosystem

#415

Post by StefanKarpinski »

StefanKarpinski wrote: post #320
renox wrote: post #294

Earlier quoted context omitted.

I remember reading a long time ago about the 1-based array and the offset-array 'kludge'. My first thought was they should have replicated Ada's design instead, my second thought I hope that they have a good linter because putting arbitrary offset implementation in a library is a minefield. I don't claim to be especially smart: this is/was obvious.. Unfortunately what isn't obvious is how to fix this issue and especi…

Offset arrays aren't a kludge and the package would exist regardless of whether zero or one has been chosen as a default base for indexing. Having arbitrary index ranges in different dimensions is extremely useful in many application domains. When working with FFTs, for example, it's natural for the indices to be symmetrical around zero. Or when doing coordinate transforms like in this example from the excellent Imag…

Here's a post I wrote on Julia discourse about why one-based indexing is not the culprit here, no matter what people may feel about it aesthetically: https://discourse.julialang.org/t/offsetarrays-inbounds-and-....

Several of the most serious scientifically minded programming languages have also had arrays that can be indexed starting at different offsets, including Fortran, Chapel and Fortress. If Julia were zero-based OffsetArrays would still exist and be highly useful. OffsetArrays is not some "kludge" just to allow indexing from zero. Frankly, indexing from zero isn't improtant enough for that. What really makes OffsetArrays useful is being able to do things like have indices go from -k:k where k may depend on the particular dimension. That way the point A[0, 0, 0] is the center of the array and you can navigate up/down/back from there naturally. Of course you can simulate that with arrays that arrays that start at zero or one, but it's a major pain.

Re: Correctness and composability bugs in the Julia ecosystem

#416

Post by pron »

Tainnor wrote: post #405
pron wrote: post #399

Earlier quoted context omitted.

That's not my insistence at all. You can believe what you like. What you can't do is make empirical assertions that we've not been able to validate empirically. Companies may adopt a technique based on empirical findings or anything else they like; most people choose a favourite programming language because they like working with it better. But the statement that types lead to fewer bugs is a very particular assertio…

I think you're guilty yourself of what you're accusing other people of. I haven't seen people ITT arguing that there is empirical evidence for types providing better correctness guarantees, just that they strongly believe it to be the case given their own experience.

The original statement was "A language with static types would have made it easier to build correct software." This is an empirical claim that the evidence does not support. Note that it's not that there's merely no evidence supporting the claim, but that studies designed to support the claim failed to do so.

Re: Correctness and composability bugs in the Julia ecosystem

#417

Post by nickitolas »

ChrisRackauckas wrote: post #349
suavesito wrote: post #337

Earlier quoted context omitted.

> So arguing "LLVM has lots of correctness bugs" is not helping the case It does not help the case about the correctness of Julia, but it does help the case about Julia having more bugs than other software (negatively for the other projects). Every library built with LLVM that touches those code paths will have those bugs. Another thing to have in mind is that Julia ships patches for some of these, that are not used…

It shows that Julia's tests are systematically finding (and leading to fixes) of numerical bugs that are pervasive throughout the rest of the LLVM ecosystem. And since Julia's LLVM is patched to solve these while other variants of LLVM are not, Julia is more correct in these aspects than other languages which rely on the Base build of LLVM. Of course Julia doesn't solve "all bugs", but some of them (like the correctn…

Do Julia devs not upstream their LLVM patches?

Re: Correctness and composability bugs in the Julia ecosystem

#418

Post by adgjlsfhk1 »

nickitolas wrote: post #417
ChrisRackauckas wrote: post #349

Earlier quoted context omitted.

It shows that Julia's tests are systematically finding (and leading to fixes) of numerical bugs that are pervasive throughout the rest of the LLVM ecosystem. And since Julia's LLVM is patched to solve these while other variants of LLVM are not, Julia is more correct in these aspects than other languages which rely on the Base build of LLVM. Of course Julia doesn't solve "all bugs", but some of them (like the correctn…

Do Julia devs not upstream their LLVM patches?

We do, but it takes a while for LLVM to accept and release patches, so by the time any one issue is fixed, there will be a new bug to take it's place.

Re: Correctness and composability bugs in the Julia ecosystem

#419

Post by pron »

jolux wrote: post #402
pron wrote: post #400

Earlier quoted context omitted.

Until it's been measured, a statement is a conjecture, not "factual." A conjecture that we've tried to verify yet failed to see a large effect is a problematic conjecture. We don't have good empirical findings about many things, most likely because many effects are small at best. But it doesn't matter. You're can say that you still believe something despite failed attempts to measure it, but you can't see it's "factu…

> That is the difference between fact and conjecture. Yes, but I'm trying to make a formal statement of fact here, not an empirical one. > I think the set of kinds of bugs that can be written in dynamic languages is a strict superset of the kinds of bugs that can be written in a static language. Here I am attempting to make a formal statement about the set of runtime behaviors that can be exhibited under static type…

> What I'm saying is that there is a set of incorrect runtime behaviors that can only be exhibited in a dynamic type system, that is, the set of type errors. I'm not aware of any runtime errors that can only be exhibited under a static type system.

But that doesn't mean they have fewer bugs! They might well have more.

> What I'm saying is that the set of possible incorrect runtime behaviors is smaller in a static language.

Not exactly. For every program in an untyped language, you could write a typed program with the exact same behaviours.

The assertion that typed programs have fewer bugs is simply false in theory, and failed to be confirmed empirically.

> However it is my belief that if there is an effect on bugs overall that it derives from what I understand to be a formal character of the runtime behavior of statically typed programs, that there are fewer ways for them to "go wrong."

I understand that that is your belief, but it is supported by neither theory nor practice.

Post reply on HN