Re: [julia-users] Re: GtkIDE.jl, a semi-functional editor for Julia

[lawrence dworsky]

Thanks for pointing me in the right direction. I had some (possibly
corrupt) junk from earlier installations. I cleaned out everything and
reinstalled Julia 0.4.5.  Everything is working fine now. GtkIDE looks real
neat.

Larry

On Thu, Apr 14, 2016 at 8:38 AM, Andreas Lobinger <lobing...@gmail.com>
wrote:

> Hello colleague,
>
> On Thursday, April 14, 2016 at 2:34:28 PM UTC+2, lawrence dworsky wrote:
>>
>> I don't seem to be able to get any of this to work.  Both Pkg.add entries
>> return
>>
>>
>> fatal: your current branch 'master' does not have any commits yet
>> ...
>> ...
>> in add at pkg.jl:23
>>
>>
>> I have no idea what this means. My installation of Julia is brand new so
>> I don't think it's messed up.
>>
>
> As the installation is brandnew, maybe something was not fully installed...
> a) what is the output of Pkg.status()?
> b) do other Pkg.add("Pkgname") work?
>

Re: [julia-users] Re: GtkIDE.jl, a semi-functional editor for Julia

[lawrence dworsky]

I don't seem to be able to get any of this to work.  Both Pkg.add entries
return


fatal: your current branch 'master' does not have any commits yet
...
...
in add at pkg.jl:23


I have no idea what this means. My installation of Julia is brand new so I
don't think it's messed up.

I appreciate your help. I'd really like to get your IDE running. It looks
great.

Larry


On Wed, Apr 13, 2016 at 3:59 PM,  wrote:

> Hum, I guess you need to add it before you can check it out :
> Pkg.add("Gtk").
>
> I'll update the readme.
>

Re: [julia-users] Re: Does Julia really solve the two-language problem?

[lawrence dworsky]

I certainly am not arguing against developing new languages with improved
programming techniques, but I think you're being too quick to consider
liking an older technique as heresy. I programmed in Fortran for over 4
decades and never had any trouble with the variable name typing system:

1.  Once you're used to it, it becomes second nature and doesn't slow down
program development at all. If anything, it speeds it up a bit.

2.  If you really hate it, you can turn it off - either selectively or
completely (implicit none).

3.  It doesn't restrict program structure or development in any way.

4.  It doesn't interact with program execution speed in any way.

This last point, I think, is very important. I'm a Julia newbe so I'm just
reading all the stuff about the interaction between variable typing and
execution speed. I've gotta tell you, having a language where I don't worry
about this at all and then the compiler handles any optimization issues has
a lot to say for it. Why is this "craziness?"

Larry


On Sun, Oct 18, 2015 at 3:06 PM, Art Kuo  wrote:

>
> Having the type of a variable be determined by the variable name is
>> craziness. Which is why you always run with implicit none.
>>
>
> It had its reason back in its day. For math it is/was typical to choose
> counter-like integers for things like a series, with variables like i, j,
> k, l, m, or n. It wasn't unreasonable to carry that convention into Fortran
> 66. Back in the days of punch cards and 1024-byte memory, variable names
> were often one letter and one alphanumeric, so the easier/shorter the
> declaration, the better. In Fortran 77, "implicit" was introduced as a way
> to maintain backwards compatibility and also optionally break from the i-n
> convention and be clear about it. Nowadays we can be thankful for upper and
> lower case, and the backspace key makes long variable names trivial.
>

Re: [julia-users] Problem getting plot() to work with 0.4.0-rc3

[lawrence dworsky]

Your link seems to refer to OSX. I'm running Windows 10.

In any case, I've tried many combinations of restarting, importing,
deleting everything and reinstalling, etc. No luck.



On Sat, Oct 3, 2015 at 10:59 AM, Yichao Yu  wrote:

> On Sat, Oct 3, 2015 at 11:46 AM, LarryD  wrote:
> > Hi
> >
> > I started by removing my old version of Julia and deleting the
> > c:\users\larry\.julia file  (Windows 10, 64 bit). Then I installed rc3.
> >
> > I tried running a program I've used before, starting with
> >
> > Pkg.add("PyPlot")
> > Pkg.update()
> > using PyPlot
> >
> > Everything seemed to be going OK until the following:
> >
> > julia> using PyPlot
> > INFO: Precompiling module PyPlot...
> > INFO: Recompiling stale cache file
> C:\Users\Larry\.julia\lib\v0.4\PyPlot.ji
> > for module PyPlot.
> > WARNING: Module BinDeps uuid did not match cache file
> > ERROR: __precompile__(true) but require failed to create a precompiled
> cache
> > file in require at loading.jl:252
> >
> > julia> x = 1:100
> > 1:100
> >
> > julia> plot(x)
> > ERROR: UndefVarError: plot not defined
> >
> > I don't know what I'm doing wrong and would greatly appreciate some help.
> >
> > Thanks,
>
> Likely https://github.com/JuliaLang/julia/issues/13200
> Try restart/import again.
>
> >
> > Larry
> >
>

Re: [julia-users] Problem getting plot() to work with 0.4.0-rc3

[lawrence dworsky]

Jackpot!  Thank you.

Just out of curiosity, when I tried deleting the entire .julia folder, it
didn't work. Why did this work?

Larry


On Sat, Oct 3, 2015 at 11:33 AM, Yichao Yu <yyc1...@gmail.com> wrote:

> On Sat, Oct 3, 2015 at 12:09 PM, lawrence dworsky
> <m...@lawrencedworsky.com> wrote:
> > Your link seems to refer to OSX. I'm running Windows 10.
>
> No, it's not. See the title of the issue and the comments below about
> seeing this on different systems.
>
> >
> > In any case, I've tried many combinations of restarting, importing,
> deleting
> > everything and reinstalling, etc. No luck.
>
> Delete C:\Users\Larry\.julia\lib\v0.4 and try again.
>
> >
> >
> >
> > On Sat, Oct 3, 2015 at 10:59 AM, Yichao Yu <yyc1...@gmail.com> wrote:
> >>
> >> On Sat, Oct 3, 2015 at 11:46 AM, LarryD <larrydwor...@gmail.com> wrote:
> >> > Hi
> >> >
> >> > I started by removing my old version of Julia and deleting the
> >> > c:\users\larry\.julia file  (Windows 10, 64 bit). Then I installed
> rc3.
> >> >
> >> > I tried running a program I've used before, starting with
> >> >
> >> > Pkg.add("PyPlot")
> >> > Pkg.update()
> >> > using PyPlot
> >> >
> >> > Everything seemed to be going OK until the following:
> >> >
> >> > julia> using PyPlot
> >> > INFO: Precompiling module PyPlot...
> >> > INFO: Recompiling stale cache file
> >> > C:\Users\Larry\.julia\lib\v0.4\PyPlot.ji
> >> > for module PyPlot.
> >> > WARNING: Module BinDeps uuid did not match cache file
> >> > ERROR: __precompile__(true) but require failed to create a precompiled
> >> > cache
> >> > file in require at loading.jl:252
> >> >
> >> > julia> x = 1:100
> >> > 1:100
> >> >
> >> > julia> plot(x)
> >> > ERROR: UndefVarError: plot not defined
> >> >
> >> > I don't know what I'm doing wrong and would greatly appreciate some
> >> > help.
> >> >
> >> > Thanks,
> >>
> >> Likely https://github.com/JuliaLang/julia/issues/13200
> >> Try restart/import again.
> >>
> >> >
> >> > Larry
> >> >
> >
> >
>

Re: [julia-users] Re: @sprintf with a format string

[lawrence dworsky]

Hi Tom

Sorry to take so long to get back to you, I had to go away for a couple of
days. Thanks for the installation information, @fmt is working fine now.
It's still not as useful as the Fortran print * formatting however because
it ​requires the user to know what's coming. For example, the Fortran code

x = -2.34e-12
do i = 1, 5
  x = -x*5000.
  print *, i, x
end do

produces

1 1.17E-08
2-5.85E-05
3 0.292500
4 -1462.5
5 7.312501e+06

As you can see, print * figured out when exponential notation is necessary
and automatically used it.

I'm retired now, but when I was working I spent a lot of time writing
numerical analysis programs for various engineering issues (elastic
material deformation, electron trajectories, etc.) While a  program was
being developed I didn't care about the aesthetics of my printout, I just
needed useful information - and early on, numerical or algebraic or
programming errors could easily produce results off by 10 order of
magnitude!

I think a capability such as this in Julia would be heavily used. I wish I
had the expertise to write it.

Larry



On Tue, Sep 22, 2015 at 4:59 PM, Tom Breloff <t...@breloff.com> wrote:

> Sorry I wasn't expecting you to run it... just comment.  You'll have to do:
>
> Pkg.rm("Formatting")
> Pkg.clone("https://github.com/tbreloff/Formatting.jl.git;)
> Pkg.checkout("Formatting", "tom-fmt")
>
> Let me know if that works.
>
> On Tue, Sep 22, 2015 at 5:52 PM, lawrence dworsky <
> m...@lawrencedworsky.com> wrote:
>
>> I'm afraid my beginner status with Julia is showing:
>>
>> I ran Pkg.add("Formatting"), and then   using Formatting   came back with
>> a whole bunch of warnings, most about  Union(args...) being depricated, use
>> Union(args) instead.
>>
>> When all is said and done,   fmt_default!  gives me a  UndefVarError.
>>
>> Help!
>>
>>
>>
>> On Tue, Sep 22, 2015 at 2:45 PM, Tom Breloff <t...@breloff.com> wrote:
>>
>>> Thanks Larry, that's helpful.  Just for discussions sake, here's a quick
>>> macro that calls my proposed `fmt` method under the hood, and does
>>> something similar to what you showed.  What do you think about this style
>>> (and what would you do differently)?
>>>
>>> using Formatting
>>>
>>> macro fmt(args...)
>>>  expr = Expr(:block)
>>>  expr.args = [:(print(fmt($(esc(arg))), "\t\t")) for arg in args]
>>>  push!(expr.args, :(println()))
>>>  expr
>>> end
>>>
>>>
>>> And then an example usage:
>>>
>>> In:
>>>
>>> x = 1010101
>>> y = 55.5
>>> fmt_default!(width=15)
>>>
>>> @fmt x y
>>>
>>> fmt_default!(Int, :commas)
>>> fmt_default!(Float64, prec=2)
>>>
>>> @fmt x y
>>>
>>>
>>> Out:
>>>
>>> 1010101  55.56
>>>   1,010,101  55.56
>>>
>>>
>>>
>>> On Tuesday, September 22, 2015 at 3:08:35 PM UTC-4, lawrence dworsky
>>> wrote:
>>>>
>>>> Hi Tom
>>>>
>>>> What I like about it is that you can just use print *, dumbly and it
>>>> always provides useful, albeit not beautiful, results. When I'm writing a
>>>> program, I use print statements very liberally to observe what's going on -
>>>> I find this more convenient than an in-line debugger.
>>>>
>>>> As the last line in my program below shows, it's easy to switch to
>>>> formatted output when you want to. The formatting capability is pretty
>>>> thorough, I'm just showing a simple example.
>>>>
>>>> This Fortran program doesn't do anything, it just illustrates what the
>>>> print statement produces:
>>>>
>>>>
>>>> real x, y
>>>> integer i, j
>>>> complex z
>>>> character*6  name
>>>>
>>>> x = 2.6
>>>> y = -4.
>>>> i = 36
>>>> j = -40
>>>> z = cmplx(17., 19.)
>>>> name = 'Larry'
>>>>
>>>> print *, x, y, i, j, z
>>>> print *, 'x = ', x, ' and j = ', j
>>>> print *, 'Hello, ', name, j
>>>> print '(2f8.3, i5)', x, y, j
>>>>
>>>> stop
>>>> end
>>>>
>>>>
>>>> The output is:
>>>>
>>>> 2.6 -4.0   36
>>>> -40  (17., 19.)
>>>> x =

Re: [julia-users] Re: @sprintf with a format string

[lawrence dworsky]

Hi Tom

What I like about it is that you can just use print *, dumbly and it always
provides useful, albeit not beautiful, results. When I'm writing a program,
I use print statements very liberally to observe what's going on - I find
this more convenient than an in-line debugger.

As the last line in my program below shows, it's easy to switch to
formatted output when you want to. The formatting capability is pretty
thorough, I'm just showing a simple example.

This Fortran program doesn't do anything, it just illustrates what the
print statement produces:


real x, y
integer i, j
complex z
character*6  name

x = 2.6
y = -4.
i = 36
j = -40
z = cmplx(17., 19.)
name = 'Larry'

print *, x, y, i, j, z
print *, 'x = ', x, ' and j = ', j
print *, 'Hello, ', name, j
print '(2f8.3, i5)', x, y, j

stop
end


The output is:

2.6 -4.0   36 -40
 (17., 19.)
x = 2.6   and j =-40
Hello, Larry -40
  2.600   -4.000  -40


Is this what you are looking for?

Larry



On Tue, Sep 22, 2015 at 11:57 AM, Tom Breloff  wrote:

> Larry: can you provide details on exactly what you like about Fortran's
> print statement?  Did it provide good defaults?  Was it easy to customize?
>
> On Tue, Sep 22, 2015 at 12:55 PM, LarryD  wrote:
>
>> Something I miss from Fortran is the very convenient default "print *,
>> . "  It handled almost 100% of my needs while working on a program and
>> was easily replaced by real formatting when the time came. Is there any
>> chance that Julia could get something like this?
>>
>> Thanks
>>
>>
>> On Monday, September 21, 2015 at 3:46:31 AM UTC-5, Ferran Mazzanti wrote:
>>>
>>> Dear all,
>>>
>>> I could use some help here, because I can't believe I'm not able to
>>> easily print formatted numbers under Julia in a easy way. What I try to do
>>> is to write a function that, given a vector, prints all its components with
>>> a user-defined format. I was trying something of the form
>>>
>>> function Print_Vec(aux_VEC,form_VEC)
>>> form_VEC :: ASCIIString
>>> str_VEC  = "%16.8f"
>>> for elem_VEC in aux_VEC
>>> str_VEC += @sprintf(form_VEC,elem_VEC)
>>> end
>>> return str_VEC
>>> end
>>>
>>> However, that doesn't work because it looks like the first argument in
>>> @sprintf must be a explicit string, and not a variable.
>>> Is there anything I can do with that?
>>>
>>> Thanks a lot for your help.
>>>
>>
>

Re: [julia-users] Re: @sprintf with a format string

[lawrence dworsky]

I'm afraid my beginner status with Julia is showing:

I ran Pkg.add("Formatting"), and then   using Formatting   came back with a
whole bunch of warnings, most about  Union(args...) being depricated, use
Union(args) instead.

When all is said and done,   fmt_default!  gives me a  UndefVarError.

Help!



On Tue, Sep 22, 2015 at 2:45 PM, Tom Breloff <t...@breloff.com> wrote:

> Thanks Larry, that's helpful.  Just for discussions sake, here's a quick
> macro that calls my proposed `fmt` method under the hood, and does
> something similar to what you showed.  What do you think about this style
> (and what would you do differently)?
>
> using Formatting
>
> macro fmt(args...)
>  expr = Expr(:block)
>  expr.args = [:(print(fmt($(esc(arg))), "\t\t")) for arg in args]
>  push!(expr.args, :(println()))
>  expr
> end
>
>
> And then an example usage:
>
> In:
>
> x = 1010101
> y = 55.5
> fmt_default!(width=15)
>
> @fmt x y
>
> fmt_default!(Int, :commas)
> fmt_default!(Float64, prec=2)
>
> @fmt x y
>
>
> Out:
>
>     1010101  55.56
>   1,010,101  55.56
>
>
>
> On Tuesday, September 22, 2015 at 3:08:35 PM UTC-4, lawrence dworsky wrote:
>>
>> Hi Tom
>>
>> What I like about it is that you can just use print *, dumbly and it
>> always provides useful, albeit not beautiful, results. When I'm writing a
>> program, I use print statements very liberally to observe what's going on -
>> I find this more convenient than an in-line debugger.
>>
>> As the last line in my program below shows, it's easy to switch to
>> formatted output when you want to. The formatting capability is pretty
>> thorough, I'm just showing a simple example.
>>
>> This Fortran program doesn't do anything, it just illustrates what the
>> print statement produces:
>>
>>
>> real x, y
>> integer i, j
>> complex z
>> character*6  name
>>
>> x = 2.6
>> y = -4.
>> i = 36
>> j = -40
>> z = cmplx(17., 19.)
>> name = 'Larry'
>>
>> print *, x, y, i, j, z
>> print *, 'x = ', x, ' and j = ', j
>> print *, 'Hello, ', name, j
>> print '(2f8.3, i5)', x, y, j
>>
>> stop
>> end
>>
>>
>> The output is:
>>
>> 2.6 -4.0   36 -40
>>  (17., 19.)
>> x = 2.6   and j =-40
>> Hello, Larry -40
>>   2.600   -4.000  -40
>>
>>
>> Is this what you are looking for?
>>
>> Larry
>>
>>
>>
>> On Tue, Sep 22, 2015 at 11:57 AM, Tom Breloff <t...@breloff.com> wrote:
>>
>>> Larry: can you provide details on exactly what you like about Fortran's
>>> print statement?  Did it provide good defaults?  Was it easy to customize?
>>>
>>> On Tue, Sep 22, 2015 at 12:55 PM, LarryD <larryd...@gmail.com> wrote:
>>>
>>>> Something I miss from Fortran is the very convenient default "print *,
>>>> . "  It handled almost 100% of my needs while working on a program and
>>>> was easily replaced by real formatting when the time came. Is there any
>>>> chance that Julia could get something like this?
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Monday, September 21, 2015 at 3:46:31 AM UTC-5, Ferran Mazzanti
>>>> wrote:
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I could use some help here, because I can't believe I'm not able to
>>>>> easily print formatted numbers under Julia in a easy way. What I try to do
>>>>> is to write a function that, given a vector, prints all its components 
>>>>> with
>>>>> a user-defined format. I was trying something of the form
>>>>>
>>>>> function Print_Vec(aux_VEC,form_VEC)
>>>>> form_VEC :: ASCIIString
>>>>> str_VEC  = "%16.8f"
>>>>> for elem_VEC in aux_VEC
>>>>> str_VEC += @sprintf(form_VEC,elem_VEC)
>>>>> end
>>>>> return str_VEC
>>>>> end
>>>>>
>>>>> However, that doesn't work because it looks like the first argument in
>>>>> @sprintf must be a explicit string, and not a variable.
>>>>> Is there anything I can do with that?
>>>>>
>>>>> Thanks a lot for your help.
>>>>>
>>>>
>>>
>>

Re: [julia-users] Re: IJulia install error

[lawrence dworsky]

I don't know. I got a specific error message that said it couldn't find a
C++ compiler and when I downloaded a compiler everything went fine.​

On Sat, Aug 29, 2015 at 8:22 AM, Steven G. Johnson stevenj@gmail.com
wrote:

 ZMQ on Windows shouldn't need a compiler installed; it downloads a
 precompiled binary.

 If the error is failed to download X then usually it means you are
 behind a firewall or something that is blocking the download.

Re: [julia-users] IJulia install error

[lawrence dworsky]

This is embarrassing - I'm not 100% sure. However, I find it in a mingw
folder, so I guess that's what I grabbed.

If you don't see a message on the REPL specifically saying that ZMQ needs
this, then​ I wouldn't bet on it helping you.

On Sat, Aug 29, 2015 at 9:29 AM, Kevin Squire kevin.squ...@gmail.com
wrote:

 Which compiler did you download (for Windows)?

 On Saturday, August 29, 2015, lawrence dworsky m...@lawrencedworsky.com
 wrote:

 I don't know. I got a specific error message that said it couldn't find a
 C++ compiler and when I downloaded a compiler everything went fine.​

 On Sat, Aug 29, 2015 at 8:22 AM, Steven G. Johnson stevenj@gmail.com
  wrote:

 ZMQ on Windows shouldn't need a compiler installed; it downloads a
 precompiled binary.

 If the error is failed to download X then usually it means you are
 behind a firewall or something that is blocking the download.

Re: [julia-users] IJulia install error

[lawrence dworsky]

I probably should also mention that this is all Windows.

On Sat, Aug 29, 2015 at 9:29 AM, Kevin Squire kevin.squ...@gmail.com
wrote:

 Which compiler did you download (for Windows)?

 On Saturday, August 29, 2015, lawrence dworsky m...@lawrencedworsky.com
 wrote:

 I don't know. I got a specific error message that said it couldn't find a
 C++ compiler and when I downloaded a compiler everything went fine.​

 On Sat, Aug 29, 2015 at 8:22 AM, Steven G. Johnson stevenj@gmail.com
  wrote:

 ZMQ on Windows shouldn't need a compiler installed; it downloads a
 precompiled binary.

 If the error is failed to download X then usually it means you are
 behind a firewall or something that is blocking the download.

Re: [julia-users] Re: Array Index Limits

[lawrence dworsky]

This sounds like the right approach. I'll try it soon and report what I
did/didn't succeed at.​  Thanks.

On Mon, Aug 17, 2015 at 6:10 PM, Matt Bauman mbau...@gmail.com wrote:

 One way to make OffsetArrays safe would be to make them index normally
 with integer indices, but introduce a *new* Integer type that gives it the
 special offset behavior.  You could name it something short, like F (for
 Fortran or oFFset) to reduce typing:

 `A[F(-10), F(0)]`

 ... and you could do even better by making it construct by multiplication
 with the typename:

 `A[-10F, 0F]`

 Or even better, you should be able to write a macro that automatically
 converts all indices to this special type:

 `@offset A[-10,0]` # This also could disallow the pesky end keyword!

 I was playing with RaggedArrays over the weekend, and there I had to solve
 a similar problem because there are two possible meanings for linear
 indexing.  So I just created a LinearIndex type that behaves differently:
 https://github.com/mbauman/RaggedArrays.jl/blob/d2b6aeb854855c7912c104cb5312c13e989f2cf4/src/core.jl#L229-L247

 Matt

 On Monday, August 17, 2015 at 4:36:27 PM UTC-4, lawrence dworsky wrote:

 Thanks for putting your time into this. Right now I'm still using 0.3.11,
 waiting for 0.4 to be the standard release. Then I'll dig into this and see
 if I get it to do what I want without undue aggravation. I had the same
 indexing issue with MatLab. Sometimes I miss the brute straightforwardness
 of Fortran.

 Larry


 On Mon, Aug 17, 2015 at 1:16 PM, Matt Bauman mba...@gmail.com wrote:

 On Monday, August 17, 2015 at 1:03:17 PM UTC-4, Sisyphuss wrote:

 I read the interfaces
 http://docs.julialang.org/en/latest/manual/interfaces/ chapter of
 the documentation today. I learned that, if you define an iterable as a
 subtype of AbstractArray, with only defining three methods (including
 `size()`, excluding `start()`), you can iterate on it just like iterate on
 an normal Array.


 Iteration should work just fine in 0.4 if OffsetArray defines its own
 `eachindex` method.

 Although more and more for loops are written generically using
 `eachindex`, there are still a lot of methods that use the old linear
 indexing standby:

 for i=1:length(A)
@inbounds A[i] = …
 end

 This is where things get really hairy for OffsetArrays.  That
 `@inbounds` propagates through to the inner array assignment, which will
 lead to silent data corruption and/or segfaults.  That's really why it
 shouldn't be an AbstractArray.

Re: [julia-users] Re: Array Index Limits

[lawrence dworsky]

Thanks. I'll check it out.

On Mon, Aug 17, 2015 at 9:11 AM, Matt Bauman mbau...@gmail.com wrote:

 See the previous discussion here:
 https://groups.google.com/forum/#!topic/julia-dev/NOF6MA6tb9Y

 … which looks like it culminated in the OffsetArrays.jl package:
 https://github.com/alsam/OffsetArrays.jl

 But you'll need to be very careful about how you use them since they break
 a core assumption about how arrays work.  I would advise against doing much
 more than scalar indexing unless you manually vet the implementations (in
 fact, it'd be safest if they weren't listed as subtypes of AbstractArray).
 And you can't use the `end` keyword safely within an indexing expression,
 either.

 Things will get a little better with 0.4, assuming OffsetArrays is updated
 to take advantage of some of the new array work there (like eachindex and
 colon lowering).  But even then, you'll still be flirting with trouble
 (which may manifest itself as silent computation errors).

 On Monday, August 17, 2015 at 9:43:13 AM UTC-4, LarryD wrote:

 Fortran offers the ability to arbitrarily set array limits, e.g. real
 x(-30:40, 0:100).  This is very useful when using an array to represent
 grid points on a dimensioned physical structure with, say, (0,0) somewhere
 in the structure. Is there any chance that this could be added to an
 upcoming version of Julia?

 LarryD

Re: [julia-users] Re: Array Index Limits

[lawrence dworsky]

Thanks for putting your time into this. Right now I'm still using 0.3.11,
waiting for 0.4 to be the standard release. Then I'll dig into this and see
if I get it to do what I want without undue aggravation. I had the same
indexing issue with MatLab. Sometimes I miss the brute straightforwardness
of Fortran.

Larry


On Mon, Aug 17, 2015 at 1:16 PM, Matt Bauman mbau...@gmail.com wrote:

 On Monday, August 17, 2015 at 1:03:17 PM UTC-4, Sisyphuss wrote:

 I read the interfaces
 http://docs.julialang.org/en/latest/manual/interfaces/ chapter of the
 documentation today. I learned that, if you define an iterable as a subtype
 of AbstractArray, with only defining three methods (including `size()`,
 excluding `start()`), you can iterate on it just like iterate on an normal
 Array.


 Iteration should work just fine in 0.4 if OffsetArray defines its own
 `eachindex` method.

 Although more and more for loops are written generically using
 `eachindex`, there are still a lot of methods that use the old linear
 indexing standby:

 for i=1:length(A)
@inbounds A[i] = …
 end

 This is where things get really hairy for OffsetArrays.  That `@inbounds`
 propagates through to the inner array assignment, which will lead to silent
 data corruption and/or segfaults.  That's really why it shouldn't be an
 AbstractArray.

Re: [julia-users] Re: Can't get PyPlot started

[lawrence dworsky]

Nope:


julia using PyCall
julia @pyimport matplotlib.pyplot as plt
ERROR: PyError (:PyImport_ImportModule) class 'ImportError'
ImportError(No module named 'six',)
  File C:\Python34\lib\site-packages\matplotlib\__init__.py, line 105, in
mod
ule
import six
 in pyerr_check at C:\Users\Larry\.julia\v0.3\PyCall\src\exception.jl:58
(repeat
s 2 times)
Julia

On Mon, Jul 20, 2015 at 2:52 PM, Steven G. Johnson stevenj@gmail.com
wrote:

 If you do

 using PyCall
 @pyimport matplotlib.pyplot as plt

 does it work?

Re: [julia-users] Re: Can't get PyPlot started

[lawrence dworsky]

You pointed me in the right direction.  My problem was in my Python
installation.  I unistalled everything Python and replaced it with the
Anaconda package. Now everything is working.

Thanks much for the quick response.

Larry​

On Mon, Jul 20, 2015 at 3:00 PM, Yichao Yu yyc1...@gmail.com wrote:

 On Mon, Jul 20, 2015 at 3:58 PM, lawrence dworsky
 m...@lawrencedworsky.com wrote:
  Nope:
 
 
  julia using PyCall
  julia @pyimport matplotlib.pyplot as plt
  ERROR: PyError (:PyImport_ImportModule) class 'ImportError'
  ImportError(No module named 'six',)

 This python ImportError seems pretty clear what's wrong... Does the
 import work in python?

File C:\Python34\lib\site-packages\matplotlib\__init__.py, line 105,
 in
  mod
  ule
  import six
   in pyerr_check at C:\Users\Larry\.julia\v0.3\PyCall\src\exception.jl:58
  (repeat
  s 2 times)
  Julia
 
  On Mon, Jul 20, 2015 at 2:52 PM, Steven G. Johnson 
 stevenj@gmail.com
  wrote:
 
  If you do
 
  using PyCall
  @pyimport matplotlib.pyplot as plt
 
  does it work?