pcre unknown error

[staticfloat]

There seems to be some weirdness with printing arrays of floats:

julia> 1:10
1:10

julia> z = sin(1:10)
10-element Float64 Array:
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef

julia> z[1]
0.8414709848078965

julia> z[1:2]
2-element Float64 Array:
 #undef
 #undef

This is on OSX 10.8, although I wonder if that can possibly have anything to do with it. :P

[StefanKarpinski]

That's weird. I wonder if you don't have to do a make cleanall testall. Jeff has done some fairly significant surgery on the internal representations of objects that could lead to strange behavior and crashes if objects are linked together that were built under different assumptions.

[StefanKarpinski]

For the record, I'm on the same setup and see normal behavior:

julia> sin(1:10)
10-element Float64 Array:
  0.841471
  0.909297
  0.14112 
 -0.756802
 -0.958924
 -0.279415
  0.656987
  0.989358
  0.412118
 -0.544021

[staticfloat]

Homebrew starts out with a fresh copy of the git repo every time you
install, so there's no need to worry about old cruft.

The test suite comes up clean, and I get #undefs in the readline, basic and
web REPLs.

[StefanKarpinski]

That is super weird. The strangest part is that you can't even actually have #undefs in arrays of floats since they aren't heap-allocated and therefore every possible value means something (possibly NaN). For performance reasons, uninitialized int, float arrays are just filled with whatever's in memory:

julia> Array(Float64,25)
25-element Float64 Array:
 2.14294e-314
 2.17901e-314
 2.12944e-314
 2.12943e-314
 2.12943e-314
 2.17668e-314
 2.12948e-314
 2.12948e-314
 2.17902e-314
 2.17901e-314
 2.17842e-314
 2.17821e-314
 2.12943e-314
 2.12944e-314
 2.1765e-314 
 2.17833e-314
 2.17842e-314
 2.14376e-314
 2.17904e-314
 2.17644e-314
 2.12943e-314
 2.12944e-314
 2.12952e-314
 2.14309e-314
 2.17821e-314

That's why I suspected recent representation changes as a culprit.

[staticfloat]

Is this printing done in Julia, or in C? If it's in Julia, where does it
happen so I can try and hunt down what's going on?

On Mon, Aug 27, 2012 at 2:18 PM, Stefan Karpinski
notifications@github.comwrote:

That is super weird. The strangest part is that you can't even actually
have #undefs in arrays of floats since they aren't heap-allocated and
therefore every possible value means something (possibly NaN). For
performance reasons, uninitialized int, float arrays are just filled with
whatever's in memory:

julia> Array(Float64,25)25-element Float64 Array:
2.14294e-314
2.17901e-314
2.12944e-314
2.12943e-314
2.12943e-314
2.17668e-314
2.12948e-314
2.12948e-314
2.17902e-314
2.17901e-314
2.17842e-314
2.17821e-314
2.12943e-314
2.12944e-314
2.1765e-314
2.17833e-314
2.17842e-314
2.14376e-314
2.17904e-314
2.17644e-314
2.12943e-314
2.12944e-314
2.12952e-314
2.14309e-314
2.17821e-314

That's why I suspected recent representation changes as a culprit.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8071092.

[StefanKarpinski]

It's in base/show.jl. Search for "#undef" and follow the breadcrumbs.

[staticfloat]

Alright, I've figured out that it has something to do with the
install_name_tool patching that I'm doing to the julia executable to get
it to fit into Homebrew.

Essentially, in your makefile, you have the line:

install_name_tool -rpath $(BUILD)/lib $(PREFIX)/lib
$(PREFIX)/bin/julia-release-readline

I patch that to be:

install_name_tool -rpath $(BUILD)/lib HOMEBREW_PREFIX/lib
$(PREFIX)/bin/julia-release-readline

This allows Julia to be installed into $HOMEBREW_PREFIX/Cellar/julia, and
have all its files tucked away in there in their own little include,
lib, bin, etc.... folders, while everything gets symlinked into
$HOMEBREW_PREFIX/{bin,lib,include}.

To accomodate this, I change the rpath so that Julia can find all of the
other libraries such as fftw which isn't sitting in Julia's
installation directory, but in its own little world in the Homebrew cellar.
Everything is symlinked into the $HOMEBREW_PREFIX directory however, so
I thought this would be enough, but apparently not.

I've confirmed that the install_name_tool step is the one that causes
Julia to not be able to print out floats in arrays, but I have no idea how
to figure out why this is happening. Is there a way to get Julia to barf on
not being able to load a dependency or something? Is there a "verbose"
mode to see what Julia has dynamically linked with, if there's a freak
accident and Julia is linking with the wrong version of some library?

Thanks!

On Mon, Aug 27, 2012 at 2:25 PM, Stefan Karpinski
notifications@github.comwrote:

It's in base/show.jlhttps://github.com/JuliaLang/julia/blob/master/base/show.jl.
Search for "#undef" and follow the breadcrumbs.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8071329.

[JeffBezanson]

The trys used to catch undefs in show.jl should check that the exception is an UndefRefError.

[staticfloat]

Is it normal for an Array of type Float to be filled with #undef's as well?

julia> Array(Float,2,2)
2x2 Float Array:
 #undef  #undef
 #undef  #undef

As opposed to:

julia> Array(Float64,2,2)
2x2 Float64 Array:
 9.88131e-324  6.94485e-310
 9.88131e-324  6.94485e-310

[StefanKarpinski]

Is it normal for an Array of type Float to be filled with #undef's as
well?

E.g.:

julia> Array(Float,2,2)
2x2 Float Array:
#undef #undef
#undef #undef

This is actually normal since Array{Float} is an array of pointers to heap-allocated objects which happen to be of type Float.

[JeffBezanson]

Come to think of it, we should probably rename Float since people probably think it is C's float type (and you can hardly blame them!) when it is actually extremely different. Maybe it should be FloatingPoint?

[StefanKarpinski]

Especially given that the analogy with Int no longer holds. FloatingPoint
is a good name.

On Tue, Aug 28, 2012 at 3:38 PM, Jeff Bezanson notifications@github.comwrote:

Come to think of it, we should probably rename Float since people
probably think it is C's float type (and you can hardly blame them!) when
it is actually extremely different. Maybe it should be FloatingPoint?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8104274.

[staticfloat]

If the big difference between Float and Float64 is that Float is Heap-allocated and Float64 is stack-allocated, I don't think FloatingPoint is such a good idea, because although you're trying to use this name to mean "Pointer to a float" it is easily confused with "Floating-point number". Therefore, to me, FloatingPoint seems exactly the same as a float from C, just slightly more verbose.

Perhaps something like HeapFloat or FloatRef or something would be better understood?

Also, @JeffBezanson; you said that the try statements should check for an UndefRefError; is there a way I can find dynamic libraries that aren't being loaded properly? So far nothing is complaining in my setup, and the test suites pass, but there's obviously a difference between when I muck around with the rpath and when I don't.

[StefanKarpinski]

No, that's not really the difference — any Julia object can be heap or stack allocated. The difference is that Float is an abstract type — there are no Float objects — there are Float32 and Float64 objects which implement the Float abstraction. Therefore, an Array{Float} has to be represented as an array of pointers to heap-allocated objects, because the actual values could be Float32 or Float64 or potentially some other implementation of Float that someone creates, say BigFloat — which can have arbitrary size. An Array{Float64}, on the other hand, has the exact same semantics but because Float64 is a concrete type and immutable, we can just store the values inline in the array like C or Fortran do. (Of course, the array itself will be heap-allocated, so they values are in the heap, but not as individual boxed values.)

So the point of FloatingPoint is that it is the abstraction of any kind of floating-point representation: Float32, Float64, Float128, BigFloat, etc. However, it is entirely possible that we should just get rid of the Float type altogether. We use it in a bunch of places, but we mostly mean Union(Float32,Float64) in all of those places and the code would probably break if BigFloat were introduced as a subtype of Float. Maybe Real should be the immediate supertype of Float32 and Float64. After all, what abstract operations make sense to anything that is a floating-point representation but don't make sense for a different representation of a real number, like a Rational? The only things I can think of are things like nextfloat which doesn't make any sense for a rational number (there is no next rational), or extracting the exponent or mantissa. In fact, nextfloat doesn't even make sense for BigFloat although extracting the exponent and mantissa as BigInt values does (I'm not sure if that's how it's done internally).

[staticfloat]

Ah, I see. That makes sense, and I agree that most people would get
confused by the difference between Float and Real, as it seems like a
very fine line to draw.

On Tue, Aug 28, 2012 at 2:06 PM, Stefan Karpinski
notifications@github.comwrote:

No, that's not really the difference — any Julia object can be heap or
stack allocated. The difference is that Float is an abstract type — there
are no Float objects — there are Float32 and Float64 objects which
implement the Float abstraction. Therefore, an Array{Float} has to be
represented as an array of pointers to heap-allocated objects, because the
actual values could be Float32 or Float64 or potentially some other
implementation of Float that someone creates, say BigFloat — which can
have arbitrary size. An Array{Float64}, on the other hand, has the exact
same semantics but because Float64 is a concrete type and immutable, we
can just store the values inline in the array like C or Fortran do. (Of
course, the array itself will be heap-allocated, so they values are in the
heap, but not as individual boxed values.)

So the point of FloatingPoint is that it is the abstraction of any kind
of floating-point representation: Float32, Float64, Float128, BigFloat,
etc. However, it is entirely possible that we should just get rid of the
Float type altogether. We use it in a bunch of places, but we mostly mean
Union(Float32,Float64) in all of those places and the code would probably
break if BigFloat were introduced as a subtype of Float. Maybe Realshould be the immediate supertype of
Float32 and Float64. After all, what abstract operations make sense to
anything that is a floating-point representation but don't make sense for a
different representation of a real number, like a Rational? The only
things I can think of are things like nextfloat which doesn't make any
sense for a rational number (there is no next rational), or extracting the
exponent or mantissa. In fact, nextfloat doesn't even make sense for
BigFloat although extracting the exponent and mantissa as BigInt values
does (I'm not sure if that's how it's done internally).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8107135.