Re: [julia-users] calling sort on a range with rev=true

[Tamas Papp]

On Mon, May 02 2016, via julia-users wrote:

> I guess it's unclear whether sort(1:3, rev=true) should return 3:-1:1 or
> [3,2,1] or be an error as it currently is.

IMO in general, all pure (non-modifying) functions that operate on
objects that are isomorphic to vectors should

1) accept all representations that collect can handle (by possibly
falling back to it), and

2) be allowed to return any representation they find convenient.

Users who want a specific form (eg a Vector) should convert
themselves. So the optimal choice would be 3:-1:1 for performance, but
users should not rely on this, and write code that would work for
[3,2,1] too.

Best,

Tamas

[julia-users] Re: calling sort on a range with rev=true

['Greg Plowman' via julia-users]

Extending/overwriting sort in range.jl (line 686)

sort(r::Range) = issorted(r) ? r : reverse(r)

with the following worked for me.

function Base.sort(r::Range; rev::Bool=false)
if rev
issorted(r) ? reverse(r) : r
else
issorted(r) ? r : reverse(r)
end
end

[julia-users] calling sort on a range with rev=true

['Greg Plowman' via julia-users]

There have been discussions about whether a range can substitute in most 
cases where a vector is required.

julia> sort(1:3)
1:3

julia> sort(1:3, rev=true)
ERROR: indexed assignment not defined for UnitRange{Int64}
 in sort! at sort.jl:222
 in sort! at sort.jl:292
 in sort! at sort.jl:402
 in sort at sort.jl:413

julia> sort(collect(1:3), rev=true)
3-element Array{Int64,1}:
 3
 2
 1



I guess it's unclear whether sort(1:3, rev=true) should return 3:-1:1 or 
[3,2,1] or be an error as it currently is.

Any thoughts?

Re: [julia-users] Image not saving

[Tim Holy]

Can you post a complete example? For example,

julia> using FileIO

julia> save("/tmp/test.png", rand(5,6))

Just Works for me. (I can open it in another program and see a small random 
checkerboard pattern.)

Also,

julia> using Images, Colors

julia> mapi = MapNone{U8}()
Images.MapNone{FixedPointNumbers.UFixed{UInt8,8}}()

julia> map(mapi, 0.6592312388568704)
UFixed8(0.659)

also works.

Is one of your packages out-of-date? Check the output of Pkg.status().

Best,
--Tim

On Sunday, May 01, 2016 12:28:06 PM yousef.k.alham...@gmail.com wrote:
> Tim,
> 
> I understand that values must fall within [0,1].
> However, rand only produces values that fall within that interval.
> 
> For some reason, the package does not seem to find that true.
> Looking at the error message, it says:
> MethodError(Images.MapNone{FixedPointNumbers.UFixed{UInt8,8}}(),(0.659231238
> 8568704,))
> 
> It thinks that 0.6592312388568704 is out-of-range or it cannot convert to
> UInt8.
> Regardless, I cannot pass UInt8 or Float64 arrays without receiving an
> error message.
> 
> Something is wrong here.
> 
> On Friday, April 29, 2016 at 4:19:16 AM UTC+3, Tim Holy wrote:
> > The key line in the error message is "out-of-range values": if you're
> > using
> > `Float64`, black corresponds to 0.0 and white corresponds to 1.0. It's
> > alerting you that some of your values went outside that range. If it
> > didn't
> > alert you to this problem in some way, then you'd wonder "how come I had
> > this
> > nice image but when I saved it and loaded the file, it was all white?" (or
> > all
> > black?)
> > 
> > If you read the message carefully, it's also telling you how to avoid this
> > 
> > problem:
> >map(Images.Clamp01NaN(img), img)
> > 
> > where `img` is your array. This function will clamp all values to between
> > 0
> > and 1, even if your image contains NaN values.
> > 
> > Best,
> > --Tim
> > 
> > On Thursday, April 28, 2016 09:46:27 AM yousef.k...@gmail.com
> > 
> >  wrote:
> > > Hello all,
> > > 
> > > I'm trying to save PNG images of the mandelbrot set.
> > > So, I've been using the package Images to do so.
> > > 
> > > To get a grip around how the package works, I've decided to test out the
> > > function "save".
> > > I've given it a filename to save in and a random two-dimensional array
> > 
> > of
> > 
> > > Float64s (Array{Float64, 2})
> > > However, it did not work.
> > > 
> > > I keep getting the following error:
> > > WARNING: Mapping to the storage type failed; perhaps your data had
> > > out-of-range values?
> > > Try `map(Images.Clamp01NaN(img), img)` to clamp values to a valid range.
> > 
> > > WARNING:
> > MethodError(Images.MapNone{FixedPointNumbers.UFixed{UInt8,8}}(),(0.6592312
> > 38> 
> > > 8568704,)) [inlined code] from .\number.jl:54
> > > 
> > > I don't really understand why this is happening.
> > > I'm currently using Julia 0.5.0-dev+3731.
> > > I've tried doing it in Julia 0.4.5, but it still doesn't work.
> > > 
> > > Is this issue common? Or is it just on my machine?
> > > Regardless, what do I need to do to get this issue resolved?
> > > 
> > > 
> > > Thank you,
> > > Yousef

[julia-users] Reactive.jl toy example problem

[JuliaFan]

Hi,

I started playing with Reactive.jl and came across some unexpected results. 
In the example below it seems that each signal is updated only once (which 
is fine) but the summation is triggered before all its inputs are 
evaluated. Is there a way to guarantee that all signal states get 
completely updated?

Thanks

using Reactive
s = Signal(0)
sc1 = map(x->2*x,s)
sc2 = map(x->3*x,s)
preserve(map(print,map(+,sc1,sc2)))

#julia> push!(s,0)
#0
#julia> push!(s,1)
#2
#julia> push!(s,2)
#7
#julia> push!(s,3)
#12
#julia> push!(s,3)
#15

Re: [julia-users] Image not saving

[yousef . k . alhammad]

Tim,

I understand that values must fall within [0,1].
However, rand only produces values that fall within that interval.

For some reason, the package does not seem to find that true.
Looking at the error message, it says:
MethodError(Images.MapNone{FixedPointNumbers.UFixed{UInt8,8}}(),(0.6592312388568704,))

It thinks that 0.6592312388568704 is out-of-range or it cannot convert to 
UInt8.
Regardless, I cannot pass UInt8 or Float64 arrays without receiving an 
error message.

Something is wrong here.


On Friday, April 29, 2016 at 4:19:16 AM UTC+3, Tim Holy wrote:
>
> The key line in the error message is "out-of-range values": if you're 
> using 
> `Float64`, black corresponds to 0.0 and white corresponds to 1.0. It's 
> alerting you that some of your values went outside that range. If it 
> didn't 
> alert you to this problem in some way, then you'd wonder "how come I had 
> this 
> nice image but when I saved it and loaded the file, it was all white?" (or 
> all 
> black?) 
>
> If you read the message carefully, it's also telling you how to avoid this 
> problem: 
>map(Images.Clamp01NaN(img), img) 
> where `img` is your array. This function will clamp all values to between 
> 0 
> and 1, even if your image contains NaN values. 
>
> Best, 
> --Tim 
>
> On Thursday, April 28, 2016 09:46:27 AM yousef.k...@gmail.com 
>  wrote: 
> > Hello all, 
> > 
> > I'm trying to save PNG images of the mandelbrot set. 
> > So, I've been using the package Images to do so. 
> > 
> > To get a grip around how the package works, I've decided to test out the 
> > function "save". 
> > I've given it a filename to save in and a random two-dimensional array 
> of 
> > Float64s (Array{Float64, 2}) 
> > However, it did not work. 
> > 
> > I keep getting the following error: 
> > WARNING: Mapping to the storage type failed; perhaps your data had 
> > out-of-range values? 
> > Try `map(Images.Clamp01NaN(img), img)` to clamp values to a valid range. 
> > WARNING: 
> > 
> MethodError(Images.MapNone{FixedPointNumbers.UFixed{UInt8,8}}(),(0.659231238 
>
> > 8568704,)) [inlined code] from .\number.jl:54 
> > 
> > I don't really understand why this is happening. 
> > I'm currently using Julia 0.5.0-dev+3731. 
> > I've tried doing it in Julia 0.4.5, but it still doesn't work. 
> > 
> > Is this issue common? Or is it just on my machine? 
> > Regardless, what do I need to do to get this issue resolved? 
> > 
> > 
> > Thank you, 
> > Yousef 
>
>

[julia-users] Re: Image not saving

[yousef . k . alhammad]

Thank you, your method saved me a lot of frustration.

On Thursday, April 28, 2016 at 8:16:12 PM UTC+3, cormu...@mac.com wrote:
>
> When I plotted a Julia set, I used this:
>
> array = Array{UInt8}(size, size, 3)
> imOutput = Images.colorim(array)
> 
>
> then for each pixel
>
> imOutput.data[x, y, :] = [r, g, b]
>
> then to output:
>
> FileIO.save(filename, imOutput)
>
>

Re: [julia-users] scope for defaults of optional and keywords arguments

[Yichao Yu]

On Sun, May 1, 2016 at 4:57 AM, Tamas Papp  wrote:
>
> On Fri, Apr 29 2016, Yichao Yu wrote:
>
>> On Fri, Apr 29, 2016 at 8:33 AM, Tamas Papp  wrote:
>>> Default value expressions for optional and keywords arguments are
>>> evaluated in the scope of the module that defines the function, which
>>> seems to be the Right Thing to do, but I could not find this specified
>>> in the manual. Did I miss it or is it just not spelled out? Asking
>>> because I would submit a correction if it is the intended behavior. Eg
>>
>> This is just the default lexical scope. Note that it is *not* the
>> module that defines the function for closures. There's already a
>> section about the scope of default arguments so it is fine if you want
>> to submit something short that clarify this a little bit.
>
> I wanted to submit a clarification but I don't understand your sentence
>
> "it is *not* the module that defines the function for closures."
>
> In the example below, I would reason about scope like this: (a
> different) bar is in the global scope for both modules, but the local

While true, the `bar` outside the scope `foo` is defined in is
irrelevant (in the sense that if `bar` isn't defined in `Foo`, `foo`
won't take it from anywhere else).

> scope of Foo.foo just takes it from Foo where it was defined (because of
> lexical scope). Is this reasoning correct?

What I mean by "not the module" is that
```
julia> function g()
   a = 1
   (b=a) -> b
   end
g (generic function with 1 method)

julia> a = 2
2

julia> g()()
1
```

This is mention in the doc
http://julia.readthedocs.io/en/latest/manual/functions/#evaluation-scope-of-default-values

> the b in a=b refers to a b in an outer scope

after the example.

>
>>
>>>
>>> --8<---cut here---start->8---
>>> module Foo
>>> bar=1
>>> foo(a=bar)=a
>>> end
>>>
>>> module Baz
>>> import Foo.foo
>>> bar=2
>>> foo2()=foo()
>>> end
>>>
>>> Baz.foo2()# will then eval to 1
>>> --8<---cut here---end--->8---
>>>
>>> Best,
>>>
>>> Tamas

[julia-users] Re: ANN: JuMP 0.13 released (or, JuMP dumps camelCase)

[Uwe Fechner]

In the announcement you wrote: "*no existing code should break after 
updating to JuMP 0.13*".

Well, it broke my code, as described in the following issue:
https://github.com/JuliaOpt/JuMP.jl/issues/753

But I found a solution:
Replace  registerNLFunction "registerNLFunction" with "JuMP.register".

It took be a while to find the correct name in the documentation.

Nevertheless, keep up the good work!

Uwe

On Saturday, April 30, 2016 at 2:33:07 AM UTC+2, Miles Lubin wrote:
>
> The JuMP team is happy to announce the release of JuMP 0.13.
>
> This is the most visible JuMP release in quite a while since *all of 
> JuMP's macros and most exported methods have been renamed* to avoid the 
> camelCase convention. The original naming scheme was put in place before 
> the 0.1 release of Julia and was never updated after the Julia community 
> converged to its current naming conventions. We don't take this change 
> lightly since it will require an update of all existing JuMP code, but we 
> believe that now, before a JuMP 1.0 release, is the best time to take these 
> steps to correct previous decisions so that we can continue to grow and 
> remain visually appealing to new users. All of these changes are simple 
> renamings, and it is sufficient to perform a find and replace on existing 
> code in order to update it. We have put deprecation warnings in place so 
> that *no existing code should break after updating to JuMP 0.13*. We 
> expect to leave these deprecations in place for quite a while (at least 6 
> months) to minimize the impact. For the definitive list of the new names, 
> see our deprecation list 
> 
> .
>
> Here's a preview of the new names:
>
> m = Model()
> @variable(m, x >= 0)
> @variable(m, y >= 0)
> @objective(m, Max, 3x-2y)
> @constraint(m, x+y <= 1)
> @constraint(m, 2x+y <= 3)
> status = solve(m)
> @show getvalue(x)
>
> Or, using the pretty block syntax:
>
> m = Model()
> @variables(m, begin
> x >= 0
> y >= 0
> end)
> @objective(m, Max, 3x-2y)
> @constraints(m, begin
> x+y <= 1
> 2x+y <= 3
> end)
> status = solve(m)
> @show getvalue(x)
>
> We request the help of the community to update existing code that may be 
> posted on the internet. If you've written a blog post, stackoverflow post, 
> public Jupyter notebook, or book(! ) 
> containing JuMP code, please make an effort to update it to the new naming 
> scheme to avoid confusing new users.
>
> I'd like to thank those who participated in the various discussions (here 
>  and here 
> ) which helped steer this 
> change in the right direction. While this release focused on simple 
> renaming, we may have some more interesting syntax changes or additions in 
> the next release, so keep an eye on the JuMP repository if you are 
> interested. For a more complete list of changes in this release, see the 
> NEWS  entry.
>
> Miles, Iain, and Joey
>
>

Re: [julia-users] scope for defaults of optional and keywords arguments

[Tamas Papp]

On Fri, Apr 29 2016, Yichao Yu wrote:

> On Fri, Apr 29, 2016 at 8:33 AM, Tamas Papp  wrote:
>> Default value expressions for optional and keywords arguments are
>> evaluated in the scope of the module that defines the function, which
>> seems to be the Right Thing to do, but I could not find this specified
>> in the manual. Did I miss it or is it just not spelled out? Asking
>> because I would submit a correction if it is the intended behavior. Eg
>
> This is just the default lexical scope. Note that it is *not* the
> module that defines the function for closures. There's already a
> section about the scope of default arguments so it is fine if you want
> to submit something short that clarify this a little bit.

I wanted to submit a clarification but I don't understand your sentence

"it is *not* the module that defines the function for closures."

In the example below, I would reason about scope like this: (a
different) bar is in the global scope for both modules, but the local
scope of Foo.foo just takes it from Foo where it was defined (because of
lexical scope). Is this reasoning correct?

>
>>
>> --8<---cut here---start->8---
>> module Foo
>> bar=1
>> foo(a=bar)=a
>> end
>>
>> module Baz
>> import Foo.foo
>> bar=2
>> foo2()=foo()
>> end
>>
>> Baz.foo2()# will then eval to 1
>> --8<---cut here---end--->8---
>>
>> Best,
>>
>> Tamas

[julia-users] reason for scoping design of for loops

[Tamas Papp]

For loops allocated new variables iff it introduces them, eg

function test1()
l = []
for i in 1:2
push!(l, ()->(j=i; i=i+1; j))
end
l
end

function test2()
l = []
i = 9   # note: only different line
for i in 1:2
push!(l, ()->(j=i; i=i+1; j))
end
l
end

function testl(l)
for i in 1:5
l[1]()
end
l[2]()
end

testl(test1())  # 2
testl(test2())  # 7

While I understand the rule and it is in accordance with the
documentation and thus not a bug, I am curious about the reasons behind
this design. At a first glance, it seems it could be a source of subtle
bugs, so there must be some advantages to balance that.

(I have searched the issues but 'for' is so common that I could not
locate anything useful --- sorry if this was discussed before).

Best,

Tamas