[julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

So I came across the concept of UNUMs on the Pony language mailing list 
 this 
morning. I hadn't heard of them before, and a quick search doesn't show up 
anything on this mailing list, so I guess most people here haven't either. 
They're a proposed alternate encoding for numbers by John L. Gustafson. 
This presentation by him sums it up nicely:

http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf

“Unums”(universal numbers) are to floating point what floating point is to 
> fixed point.
> Floating-point values self-describe their scale factor, but fix the 
> exponent and fraction size. Unums self-describe the exponent size, fraction 
> size, and inexact state, and include fixed point and IEEE floats as special 
> cases.
>

The presentation can be seen here, provided you have the Silverlight plugin:

http://sites.ieee.org/scv-cs/archives/right-sizing-precision-to-save-energy-power-and-storage

Now, I don't know enough about this topic to say if they're a good or bad 
idea, but I figured the idea is interesting/relevant enough to share with 
the Julia crowd.

I'm also wondering if they could be implemented (relatively) easily within 
Julia, given its flexible type system. If so, they might provide an 
interesting advanced example, no?

[julia-users] Re: John L. Gustafson's UNUMs

[Job van der Zwan]

On Saturday, 25 July 2015 23:34:45 UTC+3, Simon Byrne wrote:
>
> Some HN discussion here:
> https://news.ycombinator.com/item?id=9943589
>

Oh, hadn't seen that. The linked presentation is also more recent! I found 
the "slidecast" version of it, where he presents the slides in podcast form. 
 He's evangelizing a bit, but, 
well... I guess that makes sense given the topic.

I'd be keen to know more but he hasn't really published any details other 
> than his book 
> . 
> Based 
> on the free preview, it looks like a bit of a diatribe rather than a 
> detailed technical proposal, but you can look at his mathematica code here 
> 
> .
>

Well, if you decide to go against something as well-established as the way 
we've been doing integer and floating point arithmetic, you're probably 
going to need a lot of explanation in a very accessible style - because you 
definitely won't have the experts on your side.

[julia-users] Re: John L. Gustafson's UNUMs

[Job van der Zwan]

On Sunday, 26 July 2015 05:00:44 UTC+3, Scott Jones wrote:

> There also doesn't seem to be any representation of -0.0, which from what 
> I've read, is important to represent negative underflows.
>

Apparently, his format doesn't have underflow, or overflow. I'm still 
trying to wrap my head around it myself, but I *think* is that the trick is 
that it alternates between exact numbers and intervals *between* exact 
numbers. To do so it uses an "uncertainty" bit to indicate open ranges 
*between* the numbers exact numbers. The result is that all numbers can be 
represented *accurately*, but not necessarily *precise.* He kinda explains 
it here 
.

Supposedly, this solves a lot of mathematical issues.

I also wonder how well this would work for all the array based math used in 
> Julia, where you'd really like all the values to have a fixed size
> for fast indexing.
>

You could also "box" them in a fixed maximum unum size, then load/store 
them bytewise according to how big the actual numbers are. Memory-wise you 
wouldn't lose anything over floating point (unless you're at the far ends 
of the dynamic range *and* with all bits being significant digits, which I 
think is unlikely), but you wouldn't gain anything either. So most of the 
claimed energy/speed benefits would vanish, I guess, since the prefetcher 
still loads in the whole memory chunk. But perhaps in-cache there might be 
some benefits to performance. And keeping track of significant figures 
might be worth it.

Finally, I'd wonder, in the absence of hardware that could directly handle 
> UNUMs, if this would really be any better than the packing I've been doing 
> for decades (to save space in a database and in in-memory structures, where 
> things are read much more than written or modified).
>

I guess that all depends on what you mean with "better". Better 
compression? Probably not. But if the automatic-significant-figures part is 
appealing, then maybe?

[julia-users] Re: John L. Gustafson's UNUMs

[Job van der Zwan]

So on an impulse I got the ebook, and even for a physics dropout like me 
it's surprisingly engaging and accessible! There's some stuff in there that 
isn't mentioned in the online slides that might clarify the idea better.

For example, floats already have a way to represent the largest 
representable number (maxreal) and positive infinity. Add a ubit gives you 
the following:

   -  maxreal without ubit: largest rep. number
   -  maxreal with ubit: interval between maxreal and infinity
   -  infinity without ubit: infinity
   -  infinity with ubit: the interval between... infinity and beyond?

So what that gives you is a way to represent a number that is bigger than 
what you can represent, but not infinite (maxreal + ubit), and NaN 
(infinity + ubit). For negative numbers, just add sign bit.

On Sunday, 26 July 2015 13:59:33 UTC+3, Scott Jones wrote:
>
> Yes, but I could add the information about "inexact" vs. "exact" and 
> keeping track of significant figures to my format as well, while still 
> storing many common values in just 1 byte (including Null, "", and markers 
> for binary and packed Unicode text).


Well, at the very least it seems to inspire some ways you might improve 
your format! :)

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

Here's a Python port (found in the HN comments), might be worth checking 
out:

https://github.com/jrmuizel/pyunum


On Sunday, 26 July 2015 16:50:52 UTC+3, Scott Jones wrote:
>
> If you add support for this to Julia, I want to make sure I can add the 
> format to my own record storage format efficiently.
> (This sounds great!)
>
> On Sunday, July 26, 2015 at 9:09:19 AM UTC-4, Tom Breloff wrote:
>>
>> Unums as a general concept seem really interesting. I ordered the book, 
>> and may start a julia implementation (unless someone else gets there 
>> first). Unified integer and floating point with clear accuracy information 
>> could provide nice solutions for certain problems in finance and 
>> statistics. For example, I have a specialized solution to represent 
>> financial prices which have a fixed accuracy, but I want to be able to do 
>> floating point arithmetic on them. This requires lots of converting between 
>> int and float, rounding, etc. Unums may completely change those operations. 
>>
>> If anyone starts an implementation, please post the package link here so 
>> we don't duplicate efforts. 
>>
>> On Sunday, July 26, 2015, Scott Jones  wrote:
>>
>>>
>>>
>>> On Sunday, July 26, 2015 at 7:51:51 AM UTC-4, Job van der Zwan wrote:
>>>>
>>>> So on an impulse I got the ebook, and even for a physics dropout like 
>>>> me it's surprisingly engaging and accessible! There's some stuff in there 
>>>> that isn't mentioned in the online slides that might clarify the idea 
>>>> better.
>>>>
>>>> For example, floats already have a way to represent the largest 
>>>> representable number (maxreal) and positive infinity. Add a ubit gives you 
>>>> the following:
>>>>
>>>>-  maxreal without ubit: largest rep. number
>>>>-  maxreal with ubit: interval between maxreal and infinity
>>>>-  infinity without ubit: infinity
>>>>-  infinity with ubit: the interval between... infinity and beyond?
>>>>
>>>> So what that gives you is a way to represent a number that is bigger 
>>>> than what you can represent, but not infinite (maxreal + ubit), and NaN 
>>>> (infinity + ubit). For negative numbers, just add sign bit.
>>>>
>>>> On Sunday, 26 July 2015 13:59:33 UTC+3, Scott Jones wrote:
>>>>>
>>>>> Yes, but I could add the information about "inexact" vs. "exact" and 
>>>>> keeping track of significant figures to my format as well, while still 
>>>>> storing many common values in just 1 byte (including Null, "", and 
>>>>> markers 
>>>>> for binary and packed Unicode text).
>>>>
>>>>
>>>> Well, at the very least it seems to inspire some ways you might improve 
>>>> your format! :)
>>>>
>>>
>>> Yes, and I am interested in hearing about hardware support for the UNUM 
>>> format.
>>> I'm also curious about how these ideas interact with decimal floating 
>>> point (which is what I'm more familiar with, because for the sorts of 
>>> operations important for the use cases I was concerned with, not having 
>>> rounding/conversion issues between decimal <-> binary floating point or 
>>> string <-> binary floating point was critical).
>>>
>>>

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

On Wednesday, 29 July 2015 16:50:21 UTC+3, Steven G. Johnson wrote:
>
> Regarding, unums, without hardware support, at first glance they don't 
> sound practical compared to the present alternatives (hardware or software 
> fixed-precision float types, or arbitrary precision if you need it). And 
> the "ubox" method for error analysis, even if it overcomes the problems of 
> interval arithmetic as claimed, sounds too expensive to use on anything 
> except for the smallest-scale problems because of the large number of boxes 
> that you seem to need for each value whose error is being tracked. 
>

Well, I don't know enough about traditional methods to say if they're 
really as limited as Gustafson claims in his book, or if he's just 
cherry-picking. Same about the cost of using uboxe

However, ubound arithmetic tells you that 1 / (0, 1] = [1, inf), and that 
[1, inf) / inf = 0. The ubounds describing those interval results are 
effectively just a pair of floating point numbers, plus a ubit to signal 
whether an endpoint is open or not. That's a very simple thing to 
implement. Not sure if there's any arbitrary precision method that deal 
with this so elegantly - you probably know better than I do.

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

Steven, have you read the book or are you basing your judgment on the available 
presentations linked so far? Because you seem to be saying the same things 
Gustafson says, except with opposite conclusions about unums, ubounds and 
uboxes.

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

On Thursday, 30 July 2015 00:00:56 UTC+3, Steven G. Johnson wrote:
>
> Job, I'm basing my judgement on the presentation.
>

Ah ok, I was wondering I feel like those presentations give a general 
impression, but don't really explain the details enough. And like I said, 
your critique overlaps with Gustafson's own critique of traditional 
interval arithmetic, so I wasn't sure if you meant that you don't buy his 
suggested alternative ubox method after reading the book, or indicated 
scepticism based on earlier experience, but without full knowledge of what 
his suggested alternative is.

To be clear, it wasn't a "you should read the book" putdown - I hate 
comments like that, they destroy every meaningful discussion.

The more I think about it, the more I think the ubit is actually the big 
breakthrough. As a thought experiment, let's ignore the whole 
flexible-bitsize bit and just take an existing float, but replace the last 
bit of the fraction with a ubit. What happens?

Well.. we give up one bit of *precision* in the fraction, but *our set of 
representations is still the same size*. We still have the same number of 
floats as before! It's just that half of them is now exact (with one bit 
less precision), and the other half represents open intervals between these 
exact numbers. Which lets you represent the entire real number line 
accurately (but with limited precision, unless they happen to be equal to 
an exact float). 

Compare that to traditional floating point numbers, which are all exact, 
but unless your calculation is exactly that floating point representation 
(which is very rare) guaranteed to be off.

Think about it this way: regular floats represent a finite subset of 
rational numbers. More bits increase that finite subset. But add a ubit, 
and you got the entire real number line. With limited precision, and using 
the same finite number of representations as a float that has the same 
number of bits, but still.

I'd like to hear some feedback on the example I used earlier from people 
more versed in this topic than me:

 ubound arithmetic tells you that 1 / (0, 1] = [1, inf), and that [1, inf) 
> / inf = 0


Thanks to the ubit, the arithmetic is as simple as "divide by both 
endpoints to get the new interval endpoints".  It's so simple that I have a 
hard time believing this was not possible with interval arithmetic before, 
and again I don't know that much about the topic.

So is it really true, like Gustafson claims, that interval arithmetic so 
far always used *closed* intervals that accepted *rounded* answers? Because 
if that is true, and even is that is the only thing unums solve... well 
then I'm sold :P

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

BTW, Tom, I was already working on a summary of the book (on an IJulia 
notebook). I'm on mobile right now so don't have access to it, but I can share 
it later. I think something like that might be useful to attract more 
collaborators - we can't expect everyone to read it.

[julia-users] Re: ANN: Jeff Bezanson meetup talk in NYC next Tue

[Job van der Zwan]

Off-topic: the JuliaCon website still suggests registering for the event.

On Wednesday, 29 July 2015 21:10:54 UTC+2, Stefan Karpinski wrote:
>
> http://www.meetup.com/julia-nyc/events/224261149/
>
> This will have a fair amount of overlap with his keynote at JuliaCon, so 
> if you saw that you may want to skip this, but if you didn't, it's very 
> interesting and has evolved somewhat since June.
>
> Also, there's a Julia meetup group in New York. If you live in the area, 
> join the group!
>
> Stefan
>
>

Re: [julia-users] In what version is Julia supposed to "mature"?

[Job van der Zwan]

On Wednesday, 29 July 2015 19:00:38 UTC+2, Tony Kelman wrote:
>
> I guess the waters are a little muddied here lately with Rust having 
> recently put such a big emphasis on stability and reaching 1.0, actively 
> telling people not to use the language prior to that point, and seemingly 
> having really high expectations about how long 1.x will last for. They have 
> a much smaller standard library than we do, but I would think trimming ours 
> down to the bare minimum would be necessary before calling the language 
> 1.0. Maybe that could just as well be a 2.0 or 3.0 target instead. 
>

Go did the same before. I think it's because both position themselves as 
systems languages (with slightly different - but both valid - definitions 
of "systems"). I don't think the need for stability is quite as important 
for Julia - library maintainers still care of course, but there's not as 
much infrastructure built on top of Julia that depends on guaranteed 
stability.

Re: [julia-users] In what version is Julia supposed to "mature"?

[Job van der Zwan]

Let's not turn this into a tribal language pissing contest, please.

On Thursday, 30 July 2015 15:15:42 UTC+2, Tony Kelman wrote:
>
> Hah. Go's definition of "systems" is totally invalid everywhere in the 
> world except inside Google.
>
> We also have nicer syntax macros than either of those languages. Compat 
> might start getting pretty ungainly over time, but we can use REQUIRE to 
> deal with that if the version range ever gets too intractable to support 
> everything within the same set of macros.
>
>
> On Thursday, July 30, 2015 at 6:08:54 AM UTC-7, Job van der Zwan wrote:
>>
>> On Wednesday, 29 July 2015 19:00:38 UTC+2, Tony Kelman wrote:
>>>
>>> I guess the waters are a little muddied here lately with Rust having 
>>> recently put such a big emphasis on stability and reaching 1.0, actively 
>>> telling people not to use the language prior to that point, and seemingly 
>>> having really high expectations about how long 1.x will last for. They have 
>>> a much smaller standard library than we do, but I would think trimming ours 
>>> down to the bare minimum would be necessary before calling the language 
>>> 1.0. Maybe that could just as well be a 2.0 or 3.0 target instead. 
>>>
>>
>> Go did the same before. I think it's because both position themselves as 
>> systems languages (with slightly different - but both valid - definitions 
>> of "systems"). I don't think the need for stability is quite as important 
>> for Julia - library maintainers still care of course, but there's not as 
>> much infrastructure built on top of Julia that depends on guaranteed 
>> stability.
>>
>

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

On Thursday, 30 July 2015 16:07:46 UTC+2, Steven G. Johnson wrote:
>
> The problem is that if you interpret an exact unum as the open interval 
> between two adjacent exact values, what you have is essentially the same as 
> interval arithmetic.  The result of each operation will produce intervals 
> that are broader and broader (necessitating lower and lower precision 
> unums), with the well known problem that the interval quickly becomes 
> absurdly pessimistic in real problems (i.e. you quickly and prematurely 
> discard all of your precision in a variable-precision format like unums).
>
> The real problem with interval arithmetic is not open vs. closed 
> intervals, it is this growth of the error bounds in realistic computations 
> (due to the dependency problem and similar).  (The focus on infinite and 
> semi-infinite open intervals is a sideshow.  If you want useful error 
> bounds, the important things are the *small* intervals.)
>
> If you discard the interval interpretation with its rapid loss of 
> precision, what you are left with is an inexact flag per value, but with no 
> useful error bounds. And I don't believe that this is much more useful than 
> a single inexact flag for a set of computations as in IEEE.
>

The thing is, these are *exactly *the criticisms Gustafson has of 
traditional interval arithmetic. In fact, he's even more critical of 
interval arithmetic than he is of floats, as far as I can see. However, he 
claims that ubounds don't share the "absurd pessimism" problem. Supposedly, 
traditional interval arithmetic by necessity needs to be more pessimistic 
about its boundaries due to rounding, and only using closed endpoint 
instead of allowing for open intervals. Unums instead are (supposedly) more 
precise about the information loss they have, and thus (supposedly) don't 
blow up as badly. Again, his claims, not mine. I'm not saying you're wrong, 
or even sure if you disagree as much as you might think you are (although 
I'm pretty sure you wouldn't like the tone he uses when describing 
traditional methods though).

I agree with the others about the grain of salt (unums/ubounds/uboxes *always 
*come out on top in his examples, which does make you wonder), but on the 
other hand: given that the mathematica implementation of his methods are 
open source, his claims *should* be verifiable (they can be found here 
under Downloads/Updates 
,
 
Simon Byrne linked it earlier. I also found a Python port 
).

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

On Thursday, 30 July 2015 21:54:39 UTC+2, Jason Merrill wrote:

> 
>

Thanks for correcting me! The open/closed element becomes pretty crucial 
later on though, when he claims on page 225 that:

a general approach for evaluating polynomials with interval arguments 
> without any information loss is presented here for the first time.
>
 
Two pages later he gives the general scheme for it (see attached picture - 
it was too much of a pain to extract that text with proper formatting. This 
is ok under fair use right?).

Do you have any thoughts on that?

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

On Thursday, 30 July 2015 00:33:52 UTC+2, Job van der Zwan wrote:
>
> BTW, Tom, I was already working on a summary of the book (on an IJulia 
> notebook). I'm on mobile right now so don't have access to it, but I can 
> share it later. I think something like that might be useful to attract more 
> collaborators - we can't expect everyone to read it.


Ok, so since Tom is already working on a package, I moved my 
summary-in-progress to Google Drive where it's easier for people to leave 
comments:

https://docs.google.com/document/d/1d36_ppKeZDuYRadLm9-Ty8Ai2XZE5MS5bwIuEKBJ1WE/edit?usp=sharing
 

For others who have read the book, please correct any errors or 
misunderstandings on my part that you see. Expanding sections is also 
encouraged :P

Right now it's very bare-bones (since the meat is what you *can do* with 
unums, not the definition of the format itself), but I'll hopefully get 
around to expanding it a bit in the coming weeks.

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

Hey Tom,

Well, I could change the setting to "anyone with the link can edit" - we 
risk vandalism in that case, but as long as we keep the document link to 
here the risk is minimal.

On Friday, 31 July 2015 15:43:06 UTC+2, Tom Breloff wrote:
>
> I added some info to the readme at https://github.com/tbreloff/Unums.jl.  
> I talk a little bit about how I'm intending to build the package, the 
> available types, etc.  There is also a stub issue for continuing the 
> discussion of how unums fit into the world of numerical analysis: 
> https://github.com/tbreloff/Unums.jl/issues/2.  I'd love collaboration 
> from anyone that wants to help implement some of the conversion functions 
> and operations.  I don't claim to be an authority on floating point 
> arithmetic, so any and all comments are welcome.
>
> Job: Any chance you can move your google doc to a wiki or something more 
> accessible?  I'm happy to include it in my package if you want.
>
> On Thu, Jul 30, 2015 at 6:51 PM, Job van der Zwan  > wrote:
>
>> On Thursday, 30 July 2015 00:33:52 UTC+2, Job van der Zwan wrote:
>>>
>>> BTW, Tom, I was already working on a summary of the book (on an IJulia 
>>> notebook). I'm on mobile right now so don't have access to it, but I can 
>>> share it later. I think something like that might be useful to attract more 
>>> collaborators - we can't expect everyone to read it.
>>
>>
>> Ok, so since Tom is already working on a package, I moved my 
>> summary-in-progress to Google Drive where it's easier for people to leave 
>> comments:
>>
>>
>> https://docs.google.com/document/d/1d36_ppKeZDuYRadLm9-Ty8Ai2XZE5MS5bwIuEKBJ1WE/edit?usp=sharing
>>  
>>
>> For others who have read the book, please correct any errors or 
>> misunderstandings on my part that you see. Expanding sections is also 
>> encouraged :P
>>
>> Right now it's very bare-bones (since the meat is what you *can do* with 
>> unums, not the definition of the format itself), but I'll hopefully get 
>> around to expanding it a bit in the coming weeks.
>>
>
>

Re: [julia-users] John L. Gustafson's UNUMs

[Job van der Zwan]

Ah, that sounds good. So I should just fork Tom's package, copy the 
document we have so far into the wiki, then make a pull request?

On Friday, 31 July 2015 17:01:57 UTC+2, Waldir Pimenta wrote:
>
> A github wiki in the Unums.jl package would seem ideal. You get the 
> "anyone can edit" feature, with accountability of who made each edit 
> (github wikis are git repos, and to make edits people need to have a github 
> account) and easy reversal of eventual bad changes.
>
> On Friday, July 31, 2015 at 3:41:36 PM UTC+1, Job van der Zwan wrote:
>>
>> Hey Tom,
>>
>> Well, I could change the setting to "anyone with the link can edit" - we 
>> risk vandalism in that case, but as long as we keep the document link to 
>> here the risk is minimal.
>>
>> On Friday, 31 July 2015 15:43:06 UTC+2, Tom Breloff wrote:
>>>
>>> I added some info to the readme at https://github.com/tbreloff/Unums.jl.  
>>> I talk a little bit about how I'm intending to build the package, the 
>>> available types, etc.  There is also a stub issue for continuing the 
>>> discussion of how unums fit into the world of numerical analysis: 
>>> https://github.com/tbreloff/Unums.jl/issues/2.  I'd love collaboration 
>>> from anyone that wants to help implement some of the conversion functions 
>>> and operations.  I don't claim to be an authority on floating point 
>>> arithmetic, so any and all comments are welcome.
>>>
>>> Job: Any chance you can move your google doc to a wiki or something more 
>>> accessible?  I'm happy to include it in my package if you want.
>>>
>>> On Thu, Jul 30, 2015 at 6:51 PM, Job van der Zwan  
>>> wrote:
>>>
>>>> On Thursday, 30 July 2015 00:33:52 UTC+2, Job van der Zwan wrote:
>>>>>
>>>>> BTW, Tom, I was already working on a summary of the book (on an IJulia 
>>>>> notebook). I'm on mobile right now so don't have access to it, but I can 
>>>>> share it later. I think something like that might be useful to attract 
>>>>> more 
>>>>> collaborators - we can't expect everyone to read it.
>>>>
>>>>
>>>> Ok, so since Tom is already working on a package, I moved my 
>>>> summary-in-progress to Google Drive where it's easier for people to leave 
>>>> comments:
>>>>
>>>>
>>>> https://docs.google.com/document/d/1d36_ppKeZDuYRadLm9-Ty8Ai2XZE5MS5bwIuEKBJ1WE/edit?usp=sharing
>>>>  
>>>>
>>>> For others who have read the book, please correct any errors or 
>>>> misunderstandings on my part that you see. Expanding sections is also 
>>>> encouraged :P
>>>>
>>>> Right now it's very bare-bones (since the meat is what you *can do* with 
>>>> unums, not the definition of the format itself), but I'll hopefully get 
>>>> around to expanding it a bit in the coming weeks.
>>>>
>>>
>>>

Re: [julia-users] Re: John L. Gustafson's UNUMs

[Job van der Zwan]

Speaking of going out on a limb: are you aware of Mark Kikgard's work on GPU 
accelerated path rendering?

http://www.slideshare.net/mobile/Mark_Kilgard/gtc-2014-nvidia-path-rendering

There is obvious *thematic* overlap, with the promise of faster, more accurate 
2D graphics using LESS power. Rendering without artefacts at optimal speed for 
a given resolution also sounds an awful lot like "efficiently find the most 
accurate solution for a given precision" 

The going out on a limb part is the thought that just maybe the "stencil, then 
cover" approach has some complementary technical overlap with the ubox approach 
as well? Might be worth checking out.  A technical paper on the subject can be 
found here:

https://developer.nvidia.com/gpu-accelerated-path-rendering

(Frustratingly the work involves a lot of software patents 
http://patents.justia.com/inventor/mark-j-kilgard )

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Job van der Zwan]

On Monday, 19 May 2014 11:01:05 UTC+2, Simon Danisch wrote:
>
> @Job van der Zwan, can you elaborate on this?
> Voronoi diagrams sound like a nice challenge for the API.
> Delaunay-Triangulation and Voronoi diagrams are very important algorithms 
> for a lot of different use cases, like for example making a mesh out of 
> point clouds.
> Seems like some algorithms are on their way: Fast, robust predicates with 
> Julia<https://groups.google.com/forum/#!searchin/julia-users/voronoi/julia-users/rpJs7O5e0pQ/pYE8rva4FqMJ>
>

To be fair, I'm more interested in a 2D usecase than a 3D one, but I'm sure 
other people have a good use for a fast, accurate Voronoi library! 

In my case, I've been wanting to recreate Adrian Secord's work on using 
Weighted Voronoi diagrams as a way to generate stipple images[0], and then 
of course do further experiments with it (like continuing his ideas to 
decouple resolution from ink coverage). His work is over ten years old - by 
now I would have hoped computers would be fast enough to apply his 
algorithm in real-time to video-input!

A library that would allow me to just feed a set of points at once, which 
would then return the Voronoi cells and their vertices would be ideal for 
this particular use-case, but I haven't found any (they mostly focus on 
immediately *drawing* the Voronoi map), and I'm not a good enough 
programmer to implement Fortune's algorithm[1] - it has me headscratching 
at weird bugs every time I've tried it.

[0] http://cs.nyu.edu/~ajsecord/npar2002/html/index.html  (PDF version: 
http://cs.nyu.edu/~ajsecord/npar2002/npar2002_ajsecord_preprint.pdf )
[1] http://en.wikipedia.org/wiki/Fortune%27s_algorithm

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Job van der Zwan]

On Monday, 19 May 2014 18:19:53 UTC+2, Andreas Lobinger wrote:
>
>
>
> On Monday, May 19, 2014 5:40:43 PM UTC+2, Job van der Zwan wrote:
>>
>> A library that would allow me to just feed a set of points at once, which 
>> would then return the Voronoi cells and their vertices would be ideal for 
>> this particular use-case, but I haven't found any (they mostly focus on 
>> immediately *drawing* the Voronoi map), and I'm not a good enough 
>> programmer to implement Fortune's algorithm[1] - it has me headscratching 
>> at weird bugs every time I've tried it.
>>
>>  libqhull ?
>
> http://www.qhull.org/html/qvoronoi.htm 
>

Thanks you for trying to help, however:

Qhull does *not* support triangulation of non-convex surfaces, mesh 
> generation of non-convex objects, medium-sized inputs in 9-D and higher, 
> alpha shapes, *weighted Voronoi diagrams*, Voronoi volumes, or 
> constrained Delaunay triangulations,  
>

The "weighted" part is crucial to Secord's iterative algorithm.

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Job van der Zwan]

By the way, no discussion about data visualisation tools is complete 
without this design prototype by Bret Victor:

https://vimeo.com/66085662

and Victor's written addendum:

http://worrydream.com/DrawingDynamicVisualizationsTalkAddendum/

On Saturday, 17 May 2014 18:51:37 UTC+2, Simon Danisch wrote:
>
> Hi, 
> I'm currently in the planning phase for my GSOC 3D Visualization project, 
> which also means, that I need to define what the most important 
> visualization forms are.
> I must admit, that I haven't done much plotting myself, so I would have to 
> guess what the really important bits are.
> Instead of slavishly  
> imitating 
> Matlabs plot functions with some mix-ins from my side, I thought we can do 
> better, by getting feedback off the people, that actually plan to use 3D 
> plotting in Julia!
> It would help me a lot, if you could specify what you need exactly in 
> great detail.
> Just tell me what you hate about current solutions, what features you 
> really like, the format of your data, how you like to work, etc...
> Like this, I can find out what needs to be done in order to visualize your 
> data, rate the importance and difficulty and than decide in which order I 
> implement the different plotting capabilities.
> Any feedback, ideas and comments are welcome!
>
> Best wishes,
> Simon
>

[julia-users] After a recent update, Julia went from taking a while to load to starting instantly on my laptop

[Job van der Zwan]

Just curious what changed under the hood and who to thank for this 
improvement? :)

Re: [julia-users] After a recent update, Julia went from taking a while to load to starting instantly on my laptop

[Job van der Zwan]

Wow, that looks like it was a massive effort!

BTW, I subscribed to the nightly build PPA, isn't that equal to building 
from the most recent source?

On Friday, 30 May 2014 21:04:26 UTC+2, Elliot Saba wrote:
>
> This would be the static compilation work that was done for 0.3 by 
> everyone in this issue <https://github.com/JuliaLang/julia/pull/4898>. 
>  It's been available for source-built copies of julia for quite some time, 
> but was only enabled on binary builds recently.
> -E
>
>
> On Fri, May 30, 2014 at 11:17 AM, Job van der Zwan  > wrote:
>
>> Just curious what changed under the hood and who to thank for this 
>> improvement? :)
>>
>
>

Re: [julia-users] support for '?' suffix on functions that return boolean types.

[Job van der Zwan]

On Monday, 16 June 2014 03:33:32 UTC+2, Jacob Quinn wrote:
>
> it has nice discoverability properties (tab-completion)
>
Oh that's an interesting one. Never consciously thought of the interaction 
between naming conventions and autocomplete functionality before.
 

> isn't generally too awkward (though double s's are sometimes weird 
> `issubset` `issubtype`, and it took me a while to figure out isa() => is 
> a). 
>

I take it you don't like camel case? (which makes me wonder: is there a 
consensus for the idiomatic way to label multi-word identifiers in Julia?) 

[julia-users] Re: [Blog Post] A little fun with meta-programming

[Job van der Zwan]

For someone who has hardly ever used meta-programming outside of the 
creation of containers, that was really enlightening! Maybe this is old hat 
to people who work with macros all the time, or compiler writers and other 
people close to the metal, but this is the first time I've seen the concept 
of unrolling *trees**.* Is this a more generalizable technique which can 
also make sense in other data structures?

On Friday, 20 June 2014 15:09:47 UTC+2, Jacob Quinn wrote:
>
> Hey all,
>
> Thought I needed to jump on the Julia blogging train now that 
> http://www.juliabloggers.com/ is live, so feel free to check out my first 
> post!
>
> Blog post: 
> http://quinnj.github.io/2014/06/19/data-structures-as-code-the-joys-of-meta-programming/index.html
>
> Hacker News: https://news.ycombinator.com/item?id=7917724
>
> /r/programming: http://www.reddit.com/tb/28kq0n
>
> Cheers,
>
> -Jacob
>

[julia-users] Re: ANN: Processing.jl

[Job van der Zwan]

Cool! As someone who uses Processing to prototypes pretty much everything, 
I'll have a look.

One important feature is that it makes super easy to set up an interactive 
loop - your description makes it sound like it doesn't do that (yet).

Of course, the biggest draw to Processing is that it has third party 
libraries for just about anything you could possibly 
 want a library for as an 
artist. It will be a while before Julia is at that point ;)

On Sunday, 6 July 2014 18:09:02 UTC+2, Robert Ennis wrote:
>
> Hey everyone,
>
> The first basic, but usable, version of Processing.jl is up on METADATA.jl 
> as a non-tagged package. To try it out, do a Pkg.clone("Processing"). So 
> far, you can replicate some of the basic 2D drawing functionality of the 
> original Processing environment and script some basic animations by playing 
> with colours. You will find a basic example in the "test" directory of the 
> package. 3D support is on hold until the 2D support is finalised.
>
> There is nothing special about this package. It's just a small, 
> convenience wrapper around the amazing work from the people who have put 
> together the Tk.jl, Cairo.jl (w/ Pango), and Color.jl packages.
>
> Thanks for an awesome community and awesome work to build on! :)
>
> Best,
> Rob
>

[julia-users] Re: ANN: Processing.jl

[Job van der Zwan]

Ah, nice! Anyway, I ran into some trouble when trying to load the example, 
but from the looks of it the cause is not something inside Processing.js, 
right?

ERROR: win not defined
>  in include at ./boot.jl:244
>  in include_from_node1 at ./loading.jl:128
>  in eval at no file
>  in include at ./boot.jl:244
>  in include_from_node1 at ./loading.jl:128
> while loading /home/job/.julia/Processing/src/Processing2D.jl, in 
> expression starting on line 226
> while loading /home/job/.julia/Processing/test/basic2D.jl, in expression 
> starting on line 14


Linux, Ubuntu Nighty PPA.

On Tuesday, 8 July 2014 18:48:25 UTC+2, Robert Ennis wrote:
>
> Animations are there; check out the demo. I've decided to go for 
> simplicity and let the user wrap animations in loops, which should call the 
> animate() function to update the screen at the end of every "frame", rather 
> than building a draw() function that automatically and perpetually loops. 
> This actually allows for more a bit more flexibility over the animation 
> than the typical Processing approach allows. I've also abandoned the 
> setup() function, which isn't necessary here.
>
> Since this is being built on Tk (an eventual option to request Gtk will be 
> added, once functionality stabilises), this also means that we do have 
> interactivity. I'll be making that easier for users today, wrapping 
> everything in Processing friendly functions.
>
> Basic support for images, text, and spatial transformations will also be 
> updated later today.
>
> After that, I plan to make animations a bit faster, by supporting OS 
> specific drawing surfaces, rather than the general Cairo surface. Once the 
> 2D support is stabilised through Cairo + Tk/Gtk, an OpenGL based backend 
> for 2D drawing will be added.
>
> Best,
> Rob
>
> On Monday, July 7, 2014 3:53:39 PM UTC+2, Job van der Zwan wrote:
>>
>> Cool! As someone who uses Processing to prototypes pretty much 
>> everything, I'll have a look.
>>
>> One important feature is that it makes super easy to set up an 
>> interactive loop - your description makes it sound like it doesn't do that 
>> (yet).
>>
>> Of course, the biggest draw to Processing is that it has third party 
>> libraries for just about anything you could possibly 
>> <http://processing.org/reference/libraries/> want a library for as an 
>> artist. It will be a while before Julia is at that point ;)
>>
>> On Sunday, 6 July 2014 18:09:02 UTC+2, Robert Ennis wrote:
>>>
>>> Hey everyone,
>>>
>>> The first basic, but usable, version of Processing.jl is up on 
>>> METADATA.jl as a non-tagged package. To try it out, do a 
>>> Pkg.clone("Processing"). So far, you can replicate some of the basic 2D 
>>> drawing functionality of the original Processing environment and script 
>>> some basic animations by playing with colours. You will find a basic 
>>> example in the "test" directory of the package. 3D support is on hold until 
>>> the 2D support is finalised.
>>>
>>> There is nothing special about this package. It's just a small, 
>>> convenience wrapper around the amazing work from the people who have put 
>>> together the Tk.jl, Cairo.jl (w/ Pango), and Color.jl packages.
>>>
>>> Thanks for an awesome community and awesome work to build on! :)
>>>
>>> Best,
>>> Rob
>>>
>>

[julia-users] Re: ANN: Processing.jl

[Job van der Zwan]

Works now, great! Seems to "hang" when closing the window though. Will 
investigate and open an issue if it's consistent.

On Wednesday, 9 July 2014 20:13:14 UTC+2, Robert Ennis wrote:
>
> Fixed, and the demo now includes a basic example of mouse interaction. If 
> you have any further trouble, feel free to open an issue on the github 
> page: 
>
> https://www.github.com/rennis250/Processing.jl
>
> Best,
> Rob
>
> On Wednesday, July 9, 2014 10:02:40 AM UTC+2, Job van der Zwan wrote:
>>
>> Ah, nice! Anyway, I ran into some trouble when trying to load the 
>> example, but from the looks of it the cause is not something inside 
>> Processing.js, right?
>>
>> ERROR: win not defined
>>>  in include at ./boot.jl:244
>>>  in include_from_node1 at ./loading.jl:128
>>>  in eval at no file
>>>  in include at ./boot.jl:244
>>>  in include_from_node1 at ./loading.jl:128
>>> while loading /home/job/.julia/Processing/src/Processing2D.jl, in 
>>> expression starting on line 226
>>> while loading /home/job/.julia/Processing/test/basic2D.jl, in expression 
>>> starting on line 14
>>
>>
>> Linux, Ubuntu Nighty PPA.
>>
>> On Tuesday, 8 July 2014 18:48:25 UTC+2, Robert Ennis wrote:
>>>
>>> Animations are there; check out the demo. I've decided to go for 
>>> simplicity and let the user wrap animations in loops, which should call the 
>>> animate() function to update the screen at the end of every "frame", rather 
>>> than building a draw() function that automatically and perpetually loops. 
>>> This actually allows for more a bit more flexibility over the animation 
>>> than the typical Processing approach allows. I've also abandoned the 
>>> setup() function, which isn't necessary here.
>>>
>>> Since this is being built on Tk (an eventual option to request Gtk will 
>>> be added, once functionality stabilises), this also means that we do have 
>>> interactivity. I'll be making that easier for users today, wrapping 
>>> everything in Processing friendly functions.
>>>
>>> Basic support for images, text, and spatial transformations will also be 
>>> updated later today.
>>>
>>> After that, I plan to make animations a bit faster, by supporting OS 
>>> specific drawing surfaces, rather than the general Cairo surface. Once the 
>>> 2D support is stabilised through Cairo + Tk/Gtk, an OpenGL based backend 
>>> for 2D drawing will be added.
>>>
>>> Best,
>>> Rob
>>>
>>> On Monday, July 7, 2014 3:53:39 PM UTC+2, Job van der Zwan wrote:
>>>>
>>>> Cool! As someone who uses Processing to prototypes pretty much 
>>>> everything, I'll have a look.
>>>>
>>>> One important feature is that it makes super easy to set up an 
>>>> interactive loop - your description makes it sound like it doesn't do that 
>>>> (yet).
>>>>
>>>> Of course, the biggest draw to Processing is that it has third party 
>>>> libraries for just about anything you could possibly 
>>>> <http://processing.org/reference/libraries/> want a library for as an 
>>>> artist. It will be a while before Julia is at that point ;)
>>>>
>>>> On Sunday, 6 July 2014 18:09:02 UTC+2, Robert Ennis wrote:
>>>>>
>>>>> Hey everyone,
>>>>>
>>>>> The first basic, but usable, version of Processing.jl is up on 
>>>>> METADATA.jl as a non-tagged package. To try it out, do a 
>>>>> Pkg.clone("Processing"). So far, you can replicate some of the basic 2D 
>>>>> drawing functionality of the original Processing environment and script 
>>>>> some basic animations by playing with colours. You will find a basic 
>>>>> example in the "test" directory of the package. 3D support is on hold 
>>>>> until 
>>>>> the 2D support is finalised.
>>>>>
>>>>> There is nothing special about this package. It's just a small, 
>>>>> convenience wrapper around the amazing work from the people who have put 
>>>>> together the Tk.jl, Cairo.jl (w/ Pango), and Color.jl packages.
>>>>>
>>>>> Thanks for an awesome community and awesome work to build on! :)
>>>>>
>>>>> Best,
>>>>> Rob
>>>>>
>>>>

Re: [julia-users] New Julia tutorial from SciPy now online

[Job van der Zwan]

So this is an offtopic question inspired by the talk: around the 57th 
minute in the second video there's a discussion about + and +=. Although I 
didn't hear the question, I assume it was equal to mine: if we had a 
separate += operator, then *a += b* could be defined to update the fields 
of a, whereas *a = a + b* requires the creation of a new object. Since 
"don't generate garbage in the first place" is a good form of memory 
optimisation in *any *garbage collected language, that sounds like quite a 
legit use-case to me, especially in a language dedicated to number 
crunching.

Now, I assume the Julia team has also thought of this, so I'm wondering why 
it was decided to not have the possibility to overload *+=*, *-=*, 
etcetera? You could still go with *a += b* being the same as *a = a + b* if 
it isn't explicitly defined, to keep things convenient.

On Thursday, 10 July 2014 19:41:21 UTC+2, Stefan Karpinski wrote:
>
> This should absolutely be linked to from the home page – it's a really 
> great starting point for learning Julia.
>
>
> On Thu, Jul 10, 2014 at 9:12 AM, Jake Bolewski  > wrote:
>
>> Congrats David that tutorial went really well.  Perhaps now that we are 
>> going to be collecting a large number of videos about Julia these can be 
>> linked from the home page so they are bit easier to find?
>>
>> -Jake 
>>
>> On Thursday, July 10, 2014 11:13:34 AM UTC-4, John Myles White wrote:
>>
>>> This is a really great tutorial. 
>>>
>>>  -- John 
>>>
>>> On Jul 10, 2014, at 5:54 AM, David P. Sanders  
>>> wrote: 
>>>
>>> > Many thanks to all those who suffered my inane questions and helped 
>>> this to take shape, in particular: 
>>> > 
>>> > - Jeff, who persuaded me to try out Julia 
>>> > - Alonso & Luis, who convinced me that it was worth pursuing 
>>> > - The JuliaCon organizers, speakers, and participants 
>>> > - Leah for a couple of discussions about Julia tutorials 
>>> > - The Julia team at MIT who put up with me last week and moulded it: 
>>> Jiahao, Jake, Keno & Alan 
>>> > - Last, but not least, everybody who has answered my threads on 
>>> julia-users! 
>>>
>>>
>

Re: [julia-users] New Julia tutorial from SciPy now online

[Job van der Zwan]

Heh, I knew it would have been discussed to death already. Thanks for the 
quick replies!

Also, forgot to mention in the previous message, but it's a great 
introduction indeed! Had to download and play at 1.3x speed though

On Friday, 11 July 2014 22:36:45 UTC+2, Patrick O'Leary wrote:
>
> Start with the discussion in https://github.com/JuliaLang/julia/issues/249 
> and branch out from there for the discussion.
>
> On Friday, July 11, 2014 3:17:49 PM UTC-5, Job van der Zwan wrote:
>>
>> So this is an offtopic question inspired by the talk: around the 57th 
>> minute in the second video there's a discussion about + and +=. Although I 
>> didn't hear the question, I assume it was equal to mine: if we had a 
>> separate += operator, then *a += b* could be defined to update the 
>> fields of a, whereas *a = a + b* requires the creation of a new object. 
>> Since "don't generate garbage in the first place" is a good form of memory 
>> optimisation in *any *garbage collected language, that sounds like quite 
>> a legit use-case to me, especially in a language dedicated to number 
>> crunching.
>>
>> Now, I assume the Julia team has also thought of this, so I'm wondering 
>> why it was decided to not have the possibility to overload *+=*, *-=*, 
>> etcetera? You could still go with *a += b* being the same as *a = a + b* 
>> if it isn't explicitly defined, to keep things convenient.
>>
>> On Thursday, 10 July 2014 19:41:21 UTC+2, Stefan Karpinski wrote:
>>>
>>> This should absolutely be linked to from the home page – it's a really 
>>> great starting point for learning Julia.
>>>
>>>
>>> On Thu, Jul 10, 2014 at 9:12 AM, Jake Bolewski  
>>> wrote:
>>>
>>>> Congrats David that tutorial went really well.  Perhaps now that we are 
>>>> going to be collecting a large number of videos about Julia these can be 
>>>> linked from the home page so they are bit easier to find?
>>>>
>>>> -Jake 
>>>>
>>>> On Thursday, July 10, 2014 11:13:34 AM UTC-4, John Myles White wrote:
>>>>
>>>>> This is a really great tutorial. 
>>>>>
>>>>>  -- John 
>>>>>
>>>>> On Jul 10, 2014, at 5:54 AM, David P. Sanders  
>>>>> wrote: 
>>>>>
>>>>> > Many thanks to all those who suffered my inane questions and helped 
>>>>> this to take shape, in particular: 
>>>>> > 
>>>>> > - Jeff, who persuaded me to try out Julia 
>>>>> > - Alonso & Luis, who convinced me that it was worth pursuing 
>>>>> > - The JuliaCon organizers, speakers, and participants 
>>>>> > - Leah for a couple of discussions about Julia tutorials 
>>>>> > - The Julia team at MIT who put up with me last week and moulded it: 
>>>>> Jiahao, Jake, Keno & Alan 
>>>>> > - Last, but not least, everybody who has answered my threads on 
>>>>> julia-users! 
>>>>>
>>>>>
>>>

[julia-users] Re: essay on the history of programming languages

[Job van der Zwan]

By the way, is video for the Strange Loop presentation linked near the end 
 
ever going to be public?

On Sunday, 13 July 2014 04:55:43 UTC+2, Stefan Karpinski wrote:
>
> Graydon Hoare (original author of Rust) wrote a truly lovely essay in two 
> parts about the history of programming languages, the predominance of 
> two-language systems – or "Ousterhout-dichotomy languages," as he puts it – 
> Lisp's historical defiance of this dichotomy, Dylan as a successor to Lisp, 
> and finally Julia as a modern successor to Lisp and Dylan:
>
> http://graydon2.dreamwidth.org/3186.html
> http://graydon2.dreamwidth.org/189377.html
>
>
> This is a great read and an edifying historical perspective, regardless of 
> the Julia bit at the end, but may be especially interesting to folks on 
> julia-users.
>

Re: [julia-users] Re: essay on the history of programming languages

[Job van der Zwan]

I get a different message:

*Thank you for attending Strange Loop 2013*
> This is a restricted presentation that can only be viewed by Strange Loop 
> 2013 attendees!
>
Which is odd, because I didn't attend in the first place.

On Sunday, 13 July 2014 17:24:22 UTC+2, Leah Hanson wrote:
>
> Looks like it will be next month: 
> http://www.infoq.com/presentations/julia-dispatch?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=StrangeLoop2013
>
>
> On Sun, Jul 13, 2014 at 4:57 AM, Job van der Zwan  > wrote:
>
>> By the way, is video for the Strange Loop presentation linked near the 
>> end 
>> <http://nbviewer.ipython.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22> 
>> ever going to be public?
>>
>>
>> On Sunday, 13 July 2014 04:55:43 UTC+2, Stefan Karpinski wrote:
>>>
>>> Graydon Hoare (original author of Rust) wrote a truly lovely essay in 
>>> two parts about the history of programming languages, the predominance of 
>>> two-language systems – or "Ousterhout-dichotomy languages," as he puts it – 
>>> Lisp's historical defiance of this dichotomy, Dylan as a successor to Lisp, 
>>> and finally Julia as a modern successor to Lisp and Dylan:
>>>
>>> http://graydon2.dreamwidth.org/3186.html
>>> http://graydon2.dreamwidth.org/189377.html
>>>
>>>
>>> This is a great read and an edifying historical perspective, regardless 
>>> of the Julia bit at the end, but may be especially interesting to folks on 
>>> julia-users.
>>>
>>
>

Re: [julia-users] Re: essay on the history of programming languages

[Job van der Zwan]

Looking forward to it!

And thanks for helping out, Yee siang Ng!

On Monday, 14 July 2014 19:10:47 UTC+2, Stefan Karpinski wrote:
>
> Thank you! I'll work no getting this posted and hopefully we'll get an 
> InfoQ video soon.
>
>
> On Mon, Jul 14, 2014 at 12:58 AM, Yee Sian Ng  > wrote:
>
>> Attached.
>>
>>
>> On Monday, 14 July 2014 03:54:13 UTC+8, Stefan Karpinski wrote:
>>
>>> This probably because I never submitted a PDF of this talk – it was an 
>>> IPython notebook, rather than normal slides. I've repeatedly tried to use 
>>> nbconvert to turn the notebook into a PDF, but Python's package management 
>>> has defeated me every time, in the process frustrating me greatly, but also 
>>> making me much happier about Julia's package situation. So if someone who 
>>> has better python-fu than I do – or happens to have all the requisite 
>>> Python packages already installed – wants to convert this notebook from 
>>> .ipynb to some kind of PDF, then I'll send it to Alex Miller and maybe he 
>>> can get the presentation up on InfoQ. In the meantime, the CodeMesh talk I 
>>> gave a couple months later covers a lot of the same material: 
>>> http://vimeo.com/84661077 
>>> <http://www.google.com/url?q=http%3A%2F%2Fvimeo.com%2F84661077&sa=D&sntz=1&usg=AFQjCNGGnKvOHaPB9hQt-i2DOnW6tWcveQ>
>>> .
>>>
>>>
>>> On Sun, Jul 13, 2014 at 10:50 AM, Leah Hanson  
>>> wrote:
>>>
>>>> That's the first part of what I saw too. After that, it says "The 
>>>> public release of this presentation will be in the next month.".
>>>>
>>>>
>>>>
>>>> On Sun, Jul 13, 2014 at 12:13 PM, Job van der Zwan <
>>>> j.l.van...@gmail.com> wrote:
>>>>
>>>>> I get a different message:
>>>>>
>>>>> *Thank you for attending Strange Loop 2013*
>>>>>> This is a restricted presentation that can only be viewed by Strange 
>>>>>> Loop 2013 attendees!
>>>>>>
>>>>> Which is odd, because I didn't attend in the first place.
>>>>>
>>>>>
>>>>> On Sunday, 13 July 2014 17:24:22 UTC+2, Leah Hanson wrote:
>>>>>
>>>>>> Looks like it will be next month: http://www.infoq.com/pr
>>>>>> esentations/julia-dispatch?utm_source=infoq&utm_medium=QCon_
>>>>>> EarlyAccessVideos&utm_campaign=StrangeLoop2013
>>>>>>
>>>>>>
>>>>>> On Sun, Jul 13, 2014 at 4:57 AM, Job van der Zwan <
>>>>>> j.l.van...@gmail.com> wrote:
>>>>>>
>>>>>>> By the way, is video for the Strange Loop presentation linked near 
>>>>>>> the end 
>>>>>>> <http://nbviewer.ipython.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22> 
>>>>>>> ever going to be public?
>>>>>>>
>>>>>>>
>>>>>>> On Sunday, 13 July 2014 04:55:43 UTC+2, Stefan Karpinski wrote:
>>>>>>>>
>>>>>>>> Graydon Hoare (original author of Rust) wrote a truly lovely essay 
>>>>>>>> in two parts about the history of programming languages, the 
>>>>>>>> predominance 
>>>>>>>> of two-language systems – or "Ousterhout-dichotomy languages," as he 
>>>>>>>> puts 
>>>>>>>> it – Lisp's historical defiance of this dichotomy, Dylan as a 
>>>>>>>> successor to 
>>>>>>>> Lisp, and finally Julia as a modern successor to Lisp and Dylan:
>>>>>>>>
>>>>>>>> http://graydon2.dreamwidth.org/3186.html
>>>>>>>> http://graydon2.dreamwidth.org/189377.html
>>>>>>>>
>>>>>>>>
>>>>>>>> This is a great read and an edifying historical perspective, 
>>>>>>>> regardless of the Julia bit at the end, but may be especially 
>>>>>>>> interesting 
>>>>>>>> to folks on julia-users.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>

Re: [julia-users] Re: ways to improve performance of a non-integer power?

[Job van der Zwan]

On Wednesday, 16 July 2014 22:47:58 UTC+2, Stefan Karpinski wrote:
>
> On Wed, Jul 16, 2014 at 12:39 PM, Florian Oswald  > wrote:
>
>> do you think this log issue may be worth a mention in the performance 
>> tips section of the manual? I would have never guessed that there could be 
>> a fast/slow issue with such basic functions. Little do I know!
>
>
> The trouble with mentioning this is that it's an arbitrarily deep rathole. 
> Whole books could (and have) been written on this kind of optimization. But 
> perhaps a passing mention might be good.
>

A bit of a general tangent on the topic of documentation using igital 
media, but I've often wondered: why don't we use the fact that we can 
collapse/expand text blocks more often in documentation settings? (probably 
wouldn't be easily done with RTD-generated Julia documentation, but I'm 
thinking more general here). Arbitrarily deep ratholes are less of a 
problem then, as you could hide them behind expandable text, or even 
expandable text within expandable text.

Re: [julia-users] Re: Jupyter project

[Job van der Zwan]

On Wednesday, 16 July 2014 23:25:19 UTC+2, Luke Stagner wrote:
>
> The is also the alchemical symbol for oil 
>  ༜ 
>

That can be narratively made to fit with a bit of work. Julia: removing the 
mental friction from technical computing! Julia: it fuels the inner 
language nerd!

[julia-users] "Visualising Algorithms" by Mike Bostock - inspiration for iJulia feature wishlist?

[Job van der Zwan]

Hi all! I'm sure most of you have seen this come by a while ago on 
reddit/HN or the blogosphere, but nevertheless, I'd like to draw your 
attention to this wonderful interactive essay:

http://bost.ocks.org/mike/algorithms/

It really reminded me of iJulia notebooks, don't you agree?.

I was wondering if something like that is currently possible with iJulia. 
(DISCLAIMER: I haven't taken the plunge into Julia's plotting packages, as 
I'm not learning it as a scientist but just as a guy who dabbles in coding 
and is interested in new and developing languages).

For example, what if Robert Ennis' new Processing.jl 

 package 
could be used to create interactive canvas elements in iJulia?

[julia-users] Re: "Visualising Algorithms" by Mike Bostock - inspiration for iJulia feature wishlist?

[Job van der Zwan]

On Friday, 18 July 2014 11:20:15 UTC+2, Job van der Zwan wrote:
>
> Hi all! I'm sure most of you have seen this come by a while ago on 
> reddit/HN or the blogosphere, but nevertheless, I'd like to draw your 
> attention to this wonderful interactive essay:
>
> http://bost.ocks.org/mike/algorithms/
>
> It really reminded me of iJulia notebooks, don't you agree?.
>
> I was wondering if something like that is currently possible with iJulia. 
> (DISCLAIMER: I haven't taken the plunge into Julia's plotting packages, as 
> I'm not learning it as a scientist but just as a guy who dabbles in coding 
> and is interested in new and developing languages).
>
> For example, what if Robert Ennis' new Processing.jl 
> <https://groups.google.com/forum/#!searchin/julia-users/processing.jl/julia-users/nrCgpXpo49g/QutYAYioC1EJ>
>  package 
> could be used to create interactive canvas elements in iJulia?
>

And here is proof you should use the search function both here *and* on 
github before posting anything...

Looks like you guys are working on things like this already:

https://github.com/dcjones/Gadfly.jl/issues/100
https://github.com/JuliaLang/IJulia.jl/issues/107

[julia-users] Re: essay on the history of programming languages

[Job van der Zwan]

On Saturday, 19 July 2014 15:01:31 UTC+2, Tracy Wadleigh wrote:
>
> Does it count as proper, non-Alanis-style, irony that I found this thread 
> while evaluating Rust as a compliment to Julia, ala Ousterhout's dichotomy? 
> ;-)
>

Out of curiousity, what's the use-case your evaluating it for? 

[julia-users] Is there a way to directly do a clean reinstallation of a package?

[Job van der Zwan]

Somehow my Jewel installation got messed up after running Pkg.update(), 
giving me "metadata may be ahead of package" error messages. It was easy 
enough to fix: deleted the "Jewel" folder, opened Julia again and then ran 
Pkg.add("Jewel").

However, it made me wonder if a function to do all of that from the Julia 
command line might have been more appropriate - not everyone knows about 
the .julia folder, and ideally users don't need to interact with it. I 
guess I could have tried Pkg.rm followed by Pkg.add (didn't think of that 
until after fixing my issue). However, for packages indirectly installed 
because they were required by other package that would have the unwanted 
effect of them not automatically uninstalling if no other package requires 
them. (would Pkg.rm followed by Pkg.resolve have worked in that case?)

So in short: would a "Pkg.reinstall()" function be a useful addition to 
Julia?

(Apologies if this has already been discussed, I did a quick search and 
couldn't find any other discussions where this had been brought up. Given 
how obvious the functionality seems to be I probably just failed at 
searching though)

Re: [julia-users] Is there a way to directly do a clean reinstallation of a package?

[Job van der Zwan]

Ah, thanks. Hadn't thought of looking on Github.

On Monday, 11 August 2014 16:46:12 UTC+2, Isaiah wrote:
>
> Yes - just not implemented yet. See some related discussion here:
> https://github.com/JuliaLang/julia/issues/7054
>
>
>
> On Mon, Aug 11, 2014 at 7:22 AM, Job van der Zwan  > wrote:
>
>> Somehow my Jewel installation got messed up after running Pkg.update(), 
>> giving me "metadata may be ahead of package" error messages. It was easy 
>> enough to fix: deleted the "Jewel" folder, opened Julia again and then ran 
>> Pkg.add("Jewel").
>>
>> However, it made me wonder if a function to do all of that from the Julia 
>> command line might have been more appropriate - not everyone knows about 
>> the .julia folder, and ideally users don't need to interact with it. I 
>> guess I could have tried Pkg.rm followed by Pkg.add (didn't think of that 
>> until after fixing my issue). However, for packages indirectly installed 
>> because they were required by other package that would have the unwanted 
>> effect of them not automatically uninstalling if no other package requires 
>> them. (would Pkg.rm followed by Pkg.resolve have worked in that case?)
>>
>> So in short: would a "Pkg.reinstall()" function be a useful addition to 
>> Julia?
>>
>> (Apologies if this has already been discussed, I did a quick search and 
>> couldn't find any other discussions where this had been brought up. Given 
>> how obvious the functionality seems to be I probably just failed at 
>> searching though)
>>
>
>

Re: [julia-users] Re: [julia-dev] Announcing Julia 0.3.0 final

[Job van der Zwan]

Congratulations everyone!

On Thursday, 21 August 2014 08:36:32 UTC+2, Jeff Bezanson wrote:
>
> If you need code to keep working without hassle, definitely stick with 
> the 0.3 series. 
>
> Nightly builds for bleeding-edge tinkering only. 
>

I got the impression some packages tend to break if they update and you 
weren't up to date with the latest nightly? Was that an exceptional 
situation as we converged to 0.3?

Re: [julia-users] Re: [julia-dev] Announcing Julia 0.3.0 final

[Job van der Zwan]

Thanks for the explanations!

If I switch the Ubuntu PPA to stable builds, is it advisable that I do a 
clean installation of all packages too? Or does the Julia package manager 
also automatically fix that?

On Thursday, 21 August 2014 10:06:30 UTC+2, Elliot Saba wrote:
>
> Ideally this should not happen, however due to the large amount of 
> functionality offered in Julia 0.3 as compared to 0.2, many packages became 
> 0.3-compatible only.  In that case, of course, you have no choice but to 
> use 0.3 nightlies in order to use those packages.
>
> In the 0.4 development cycle, we're trying to break things down into 
> slightly more granular chunks: We're officially designating these first few 
> crazy months as the 0.4.0-dev period, (reflected in the version numbers of 
> nightlies) wherein everything is fair game for breakage, and some packages 
> will likely break.
>
> Once most big changes have had a chance to settle and we start thinking 
> about releasing 0.4.0, we will transition to the 0.4.0-pre phase.  This is 
> where a much larger percentage of the userbase can think about starting to 
> use nightly builds, similar to a beta.  After that of course, we enter the 
> familiar release candidate phase, followed by a final release.
>
> We don't suggest that people who want to use a stable environment use the 
> 0.4.0-dev builds, as I can almost guarantee you a lot of packages will 
> break as soon as we merge a few of the upcoming big changes.  It's possible 
> there will be packages that will require 0.4.0-dev features, but most 
> packages that work now should still be compatible with 0.3.0 in the future. 
>  That is, after all, what our package manager is meant to do.
> -E
>

[julia-users] Re: Does Julia have something similar to Python's documentation string?

[Job van der Zwan]

Any plans? Discussions on Github worth reading through?

I personally am really charmed by the godoc 
 approach - could 
something like that work for Julia? (so figuring out a sensible idiomatic 
way to document functions and modules that makes the documentation easy to 
read in plaintext, but also easy to be turned into pretty formatted 
documentation by tools)

On Sunday, 24 August 2014 23:07:30 UTC+2, Ivar Nesje wrote:
>
> Not yet. 

Re: [julia-users] Re: Does Julia have something similar to Python's documentation string?

[Job van der Zwan]

On Monday, 25 August 2014 01:23:26 UTC+2, Jason Knight wrote:

> Happy reading: https://github.com/JuliaLang/julia/issues/3988 :)
>

Thanks, that was indeed interesting :)

On Monday, 25 August 2014 01:43:11 UTC+2, Stefan Karpinski wrote:
>
> I really like godoc – that's basically what I want plus a convention that 
> the doc strings are markdown.
>

>From what I understand of the discussion linked above, the suggested 
approach is a @doc macro followed by a string, making documentation part of 
compiling the code, correct? The godoc approach is different in two ways: 
documentation is not part of the runtime but a separate tool that parses Go 
source files, and it extracts documentation from the *comments*, based on 
where they are placed.

The former part of the difference is just a consequence of how Go and Julia 
are used differently, so probably not that relevant, but Go's approach of 
using comments to indicate documentation sounds more sensible to me - 
documentation is what comments are for, are they not? Then why not suggest 
an idiomatic way to use the comments, and make a tool/the Julia runtime 
capable of extracting documentation information from that structure?

Mind you, I don't use Python so perhaps this is also a personal matter of 
not being used to docstrings.

Re: [julia-users] Re: Does Julia have something similar to Python's documentation string?

[Job van der Zwan]

On Tuesday, 26 August 2014 00:04:41 UTC+2, John Myles White wrote:
>
> The issue is that you want to have all code documentation show up in REPL. 
> In the GoDoc approach, this might require an explicit "build" step -- which 
> is a non-trivial cost in usability.
>
>  -- John
>

I assume you talking about GoDoc as a tool?

In case you are referring to comments as the source of documentation 
instead of docstrings: I assume comments are now simply discarded during 
compilation, making it impossible to use them for documentation, but if 
that could be changed they should be just as valid as the format for 
documentation, right?

Re: [julia-users] Does Julia have something similar to Python's documentation string?

[Job van der Zwan]

Right, that's what I meant with GoDoc being a separate tool: Go is 
statically compiled and does not have something like a REPL or runtime 
evaluation, so being a separate tool is only logical. In that sense it's 
not a comparable situation.

The comments-as-documentation and the conventions used to make it work 
might still be worth looking into. 

I personally feel that from the point of view of people using Julia it's a 
better option than introducing docstrings - comments are already the 
source-level form of documentation-for-humans after all. Introducing 
docstrings feels like creating two different options for the same role, 
except one is ignored by tools and the other isn't. That just *feels* 
unelegant to me (not the strongest argument, I know), and I worry that code 
with both would become visually more noisy.

I just googled for possible reasons for having both docstrings and 
comments, and the only argument I found is that one describes the *what* 
and the other a *how*. GoDoc only counts comments above the 
package/variable/function definition as documentation, and ignoring 
comments inside a function body or struct definition. Since the former 
typically documents the *what* and the latter the *how* anyway, that 
distinction automatically emerges through convention.

Of course, if "not discarding comments during compilation" would require a 
major overhaul to the compiler and docstrings are technically much easier 
to introduce I can understand if that option is more appealing - a less 
elegant feasible solution is better than an inelegant infeasable one. And 
perhaps there are other arguments in favour of having both docstrings and 
comments that I'm not aware of?

On Tuesday, 26 August 2014 17:34:24 UTC+2, Stefan Karpinski wrote:
>
> To clarify – I meant that I like the style of GoDoc, not the fact that you 
> run the tool as a separate pass. That doesn't strike me as completely out 
> of the question, but wouldn't be optimal.
>
>
> On Tue, Aug 26, 2014 at 11:32 AM, John Myles White  > wrote:
>
>> No, I was talking about what I understood to be a design principle of 
>> GoDoc: doc generation and parsing occurs at doc-gen time, not at run-time.
>>
>> Yes, you would have to make comments non-ignorable to get this to work.
>>
>>  — John
>>
>> On Aug 26, 2014, at 12:44 AM, Job van der Zwan > > wrote:
>>
>> On Tuesday, 26 August 2014 00:04:41 UTC+2, John Myles White wrote:
>>>
>>> The issue is that you want to have all code documentation show up in 
>>> REPL. In the GoDoc approach, this might require an explicit "build" step -- 
>>> which is a non-trivial cost in usability.
>>>
>>>  -- John
>>>
>>
>> I assume you talking about GoDoc as a tool?
>>
>> In case you are referring to comments as the source of documentation 
>> instead of docstrings: I assume comments are now simply discarded during 
>> compilation, making it impossible to use them for documentation, but if 
>> that could be changed they should be just as valid as the format for 
>> documentation, right?
>>
>>
>>
>

Re: [julia-users] Does Julia have something similar to Python's documentation string?

[Job van der Zwan]

Could we not have both, in a way? A sensible convention for comment-based 
documentation using markdown, which I expect covers the vast majority of 
usecases (being human-readable plaintext that converts to rich text). 
During compilation that documentation is converted and added to the global 
dictionary of metadata you propose.

So in the following case:

# documentation of function f
# foo
# [bar](http://example.com)
function f()

f() would be the key in the global dictionary, and the preceding the 
comments would be converted to markdown format and associated with that key.

I'm sure that would cover the majority of the usecases, and lead to 
prettier, well documented plain text source code. At the same time the 
machinery you suggested can be added to it for the more complicated cases 
that need it.

On Thursday, 28 August 2014 12:31:19 UTC+2, Steven G. Johnson wrote:
>
> Another problem with using comments, besides the requirement that Stefan 
> pointed out of a separate processing pass (as opposed to automatic 
> availability of metadata at runtime like in Python) is that then the 
> metadata is not Julia: we lose the flexibility of the metadata being 
> arbitrary Julia objects, as opposed to just strings.
>
> My proposal (in the abovementioned issue) is that the metadata be any 
> Julia object, when then gets converted into output formats by using 
> writemime methods.   For example, if the object has writemime(io, 
> "text/markdown", x), then you can get output in Markdown format (probably 
> faciliated by an md"" constructor).   But if at some later point in 
> time you want to attach SVG documentation, or some future documentation 
> format, then you can easily do that by defining an appropriate container 
> object.   And since the objects can be queried to find out what MIME 
> formats they support, you can perform automated translation between 
> different formats (e.g. conversion of markdown and plain-text docstrings to 
> HTML or LaTeX output).
>
> Of course, with comment-based documentation then we could theoretically 
> embed a little programming language (TeX?) in the comments to achieve the 
> same thing, but since we already have a perfectly good programming language 
> (we hope!), this seems silly.   It is more likely that a comment-based 
> documentation implementation would use a fixed format, something we are 
> then stuck with for all time.
>

Re: [julia-users] Does Julia have something similar to Python's documentation string?

[Job van der Zwan]

On Friday, 29 August 2014 12:59:21 UTC+2, Steven G. Johnson wrote:
>
> And if you sacrifice flexibility, you might easily end up with something 
> that works for now, but is an annoyance in a few years.  (It is really hard 
> to add more structured information into Python docstrings, for example.)
>

If you include programmability and flexibility when it's not needed, you 
invite abuse. *Especially* if the target audience isn't primarily trained 
as programmers. We could choose to have different multiline comments count 
as different documentation blocks, and allow declaring a mimetype per 
comment block:

#=
  no mimetype, defaults to markdown
=#
#= image/svg+xml
  [svg data, or link to source]
=#
function f()

That should give enough flexibility and room for growth, I would say.

I think putting documentation in something that is not syntactically 
> meaningful -- comments -- will get more and more annoying, because you'll 
> end up inventing more and more ad-hoc rules for how to associate which 
> documentation with which object


First, if we design a proper convention for comments to have them work as a 
form of documentation, then don't they by definition become syntactically 
meaningful? It's a bit of a false premise. Also, the association works the 
same way it works for code: by placing the right tokens next to each other, 
following a certain standard.
 

> e.g. how do you associate the docstring comment with a constant?
>

Is the constant publically visible? Then it's probably top level, so a 
comment directly above it works. That's what Go does.
 

>   with a Function as opposed to a specific method
>

Ok, I admit this one is a bit trickier. But if we still have the 
store-in-a-dictionary approach you proposed (which as far as I can see does 
not conflict with comment-based documentation) one can directly add 
documentation to the dictionary in the same way one would for any 
dictionary.
 

> Not to mention that the documentation system will have to decide which 
> comments are docstrings and which comments are just internal comments by 
> programmers who didn't intend for the comment to be an end-user doc.
>

That is essentially arguing using a convention is a bad idea because some 
people won't be aware of it and accidentally will show comments not 
relevant to the outside world, yet I have seen no examples of this 
confusion in the Go community.

Re: [julia-users] Does Julia have something similar to Python's documentation string?

[Job van der Zwan]

As an interaction designer I think there could also be another way to 
approach this problem - from the user's point of view.

I'd say there's two users to keep in mind here:

- the person who writes the documentation
- the person who reads the documentation

We need to ask: when will the users want do this, and how? 

In the readers case, there's plenty of places. When looking up what a 
function does in IJulia - nice formatting, searchability a la Hoogle seem 
valuable here. When reading the source code of a .jl code directly is also 
an option. Then we want to have a convention that ensures the documentation 
is nicely laid out among the code - comment-based documentation with a 
convention that guides good code commenting (a la Go) makes more sense here.

In the writers case, perhaps in the repl? Then a macro attaching 
documentation to an existing function makes sense. In a .jl source file? In 
the latter case, I think it makes more sense to have the documentation 
right next to the thing being documented, following a sensible convention 
for readability.

[julia-users] Re: ANN: FastAnonymous

[Job van der Zwan]

Cool.

So as someone who doesn't use anonymous functions enough to understand the 
fine details: is this a stopgap solution, or a "won't be part of base 
because it makes a certain trade-off"-solution?

On Thursday, 4 September 2014 00:29:31 UTC+2, Tim Holy wrote:
>
> I'm pleased to announce the availability of the FastAnonymous package: 
> https://github.com/timholy/FastAnonymous.jl 
>
> Those of you who have used Julia for a while may know that things such as 
>  map(myfunction, collection) 
> do not have ideal performance, and particularly the anonymous-function 
> version 
> map(x->x^2, collection) 
> is quite slow. FastAnonymous provides a simple mechanism for getting 
> inlined 
> performance for arbitrary functions, even those that require additional 
> parameters. Please see the README for details. 
>
> In this context it's also worth reminding folks of the existence of 
> Dahua's 
> excellent NumericFuns, which provides partially-overlapping functionality 
> with 
> a different API. 
>
> Best, 
> --Tim 
>
>

[julia-users] Re: PSA: Light Table Plugin Rename

[Job van der Zwan]

Hmm, is there a way to set up LT so that it always runs Pkg.update() when 
you boot it or before updating the Juno plugin? (not suggesting this as 
default behaviour of course)

On Thursday, 4 September 2014 01:36:57 UTC+2, Mike Innes wrote:
>
> Ok, give Pkg.update() a go
>
> On Wednesday, 3 September 2014 18:55:04 UTC-4, David P. Sanders wrote:
>>
>>
>> OK, I worked out how to clear the console (right-click on the console 
>> space).
>>
>> Then when I click anywhere, I get
>>
>>
>>- 
>>
>>WARNING: LightTable.jl: stat: too many symbolic links encountered (ELOOP)
>> in stat at ./stat.jl:43
>> in isdir at stat.jl:103
>> in filter! at array.jl:1214
>> in dirs at /Users/dsanders/.julia/v0.3/Jewel/src/module.jl:16
>> in dirsnearby at /Users/dsanders/.julia/v0.3/Jewel/src/module.jl:36
>> in find_include at /Users/dsanders/.julia/v0.3/Jewel/src/module.jl:74
>> in filemodule at /Users/dsanders/.julia/v0.3/Jewel/src/module.jl:85
>> in anonymous at 
>> /Users/dsanders/.julia/v0.3/Jewel/src/LightTable/misc.jl:4
>> in handle_cmd at 
>> /Users/dsanders/.julia/v0.3/Jewel/src/LightTable/LightTable.jl:65
>> in server at 
>> /Users/dsanders/.julia/v0.3/Jewel/src/LightTable/LightTable.jl:22
>> in server at /Users/dsanders/.julia/v0.3/Jewel/src/Jewel.jl:18
>> in include at ./boot.jl:245
>> in include_from_node1 at loading.jl:128
>> in process_options at ./client.jl:285
>> in _start at ./client.jl:354
>> in _start at /Users/dsanders/development/julia/usr/lib/julia/sys.dylib
>>
>>
>>
>>
>> El miércoles, 3 de septiembre de 2014 15:58:54 UTC-5, Mike Innes escribió:
>>>
>>> Hey all,
>>>
>>> Following IPython's rename to Jupyter I've updated the name of the 
>>> Jupiter plugin in LT's plugin manager. If you have "Jupiter" or "Jewel" 
>>> currently installed in Light Table, please remove them from the plugin 
>>> manager.
>>>
>>> You can then reinstall the plugin by searching for "Juno" (the raw Julia 
>>> plugin is now simply called "Julia").
>>>
>>> On the plus side I just released 0.8 with improved support for data 
>>> frames and an object browser, so it should be worth the upgrade. Let me 
>>> know if you have any questions or problems.
>>>
>>> – Mike
>>>
>>

[julia-users] Re: ANN: revamped Images based on Color, FixedPointNumbers

[Job van der Zwan]

On Friday, 5 September 2014 23:07:05 UTC+2, Tim Holy wrote:
>
> Compared to other image-processing packages you may 
> have used before, no longer do you have to retain a mental separation 
> between 
> integer-valued images (spanning 0 to 255, for example) and floating point- 
> valued images (spanning 0 to 1). Moreover, if you're using a 12-bit (or 
> 14-bit 
> or ...), you'll find that there are types that map 12 bits to 0 to 1 
> already 
> waiting for you. 
>

This sounds like Julia magic that will greatly simplify a *lot* of code.

[julia-users] Colour blind friendly defaults for plotting?

[Job van der Zwan]

This is inspired by this "speed vs LOC" graph from an earlier discussion 
(dug up by Steve):
https://groups.google.com/d/msg/julia-users/BYRAeQJuvTw/O7VK7-vp1EEJ

Because of my protanomaly 
,
 
I cannot distinguish the Lua, Julia or Octave dots in that picture (or C, 
Python and JavaScript).

The thing about plotting packages is that you have to meet the needs of two 
audiences for it: those who produce graphs with it, and those who will read 
the graphs produced by it, which is a bit of different need than creating a 
script for yourself. This is part of why it is such an overlooked issue: 
most people who will make a plot are not colour blind themselves.

Which made me think: instead of a colour blind person asking for a colour 
blind-friendly version of a graph every time (or suffering in silence, 
because honestly, I feel like I'm whining when I do this), why not give the 
plotting packages have more colour blind-friendly defaults? That way most 
of these issues would be resolved without requiring conscious effort by 
those using the plotting packages. There's ways of doing so without making 
the "normal vision" people suffer too.

For example, us a form of CubeHelix or similar smartly designed palette as 
the default palette:
http://www.ifweassume.com/2013/05/cubehelix-or-how-i-learned-to-love.html
https://www.mrao.cam.ac.uk/~dag/CUBEHELIX/

Another option would be to use different shapes for different data points, 
instead of dots for everything.

Both of these options have the advantage that they would reduce issues with 
printing graphs in black and white too!

Thoughts?

[julia-users] Re: Colour blind friendly defaults for plotting?

[Job van der Zwan]

@Tamas: Glad I could point out a possible solution for you :)

@Ivar: Nice discussion - I just *knew* you guys would have talked about 
this before ;). Great to see you have already put effort into this! 

That is very impressive. My main take away is that this is a completely 
> incomprehensible way to present this data no matter how good your colour 
> scheme is :-)


For the record, I'm going to steal this remark by Stefan Karpinski next 
time I have to discuss data visualisations with people.

@Daniel: Hadn't thought of the RGB issue. Then again, the algorithm behind 
CubeHelix is fairly simple and highly tweakable (it can pretty much be 
explained by it's title alone, after all). Couldn't it just be plugged 
into, say, CIELAB colour space with equally useful but more pleasing 
results? A quick google search suggest someone has already tried this, 
although it comes without pictures so I can't verify what it produces 
myself:

COLOR HELIX:
>  

 

This Fortran90 program is an improvement of Cube helix making use of the 
> CIE LAB (1976)
> color space. Optionally, the original cube helix method is also included. 
> COLOR HELIX
> generates RGB palettes which can be used in gnuplot. Color helix is best 
> compiled with
> the free GNU Fortran Compiler.


https://astro.uni-bonn.de/~ithies/
https://astro.uni-bonn.de/~ithies/gnuplot/colortools/README

Of course, I'm more than happy to be a guinnea pig for any further tweaks! 
As you pointed out, there can't be a "one size fits all" solution, if only 
because different data visualisations have different needs - a heat map is 
fundamentally different from a scatter plot.

I think the main take-away from my original message would be: rather than 
jumping through hoops to get a perfect colour scheme for ever form of 
colour vision (although by all means, lets try!), add redundancy where 
sensible so you don't *have* to rely on colours alone. Lightness, shape and 
texture can all help here, and with a bit of work will likely benefit 
*every* form of vision.

PS: I accidentally wrote "Steve" when I wanted to refer to Stefan Karpinsky 
in the opening post. Sorry about that.

[julia-users] Re: Colour blind friendly defaults for plotting?

[Job van der Zwan]

BTW, would it make more sense to (re)open an issue on github about this, 
and if so: where? Because there are multiple plotting packages, right?

[julia-users] Re: Colour blind friendly defaults for plotting?

[Job van der Zwan]

On Monday, 9 February 2015 23:50:26 UTC+1, Daniel Jones wrote:
>
> The Color <https://github.com/JuliaLang/Color.jl> package would be a good 
> place to open an issue. If improvements are made there, all plotting 
> packages should be able to reap the benefits.
>
> On Monday, February 9, 2015 at 2:34:43 PM UTC-8, Job van der Zwan wrote:
>>
>> BTW, would it make more sense to (re)open an issue on github about this, 
>> and if so: where? Because there are multiple plotting packages, right?
>>
>
Right, that makes perfect sense for the cubehelix colour scheme, so I 
opened an issue for that here 
<https://github.com/JuliaLang/Color.jl/issues/78>. 

The other suggestion I had was using different shapes and textures when 
possible. Should I open a separate issue with those suggestions on each 
plotting package?

[julia-users] Re: Julia Summer of Code

[Job van der Zwan]

On Monday, 25 May 2015 16:26:34 UTC+2, Shantanu Raj wrote:
>
> I am hoping to join JSOC to apply for the autoformat-tool 
>  project, it 
> would be great to have one for Julia too. The project can eventually be 
> extended to a Sublime Text/Atom plugin ala. GoSublime.
>
> I am looking for a mentor, I have the time to devote to the project. 
> Though I am a beginner in Julia programming currently, but I can learn 
> fast. I have worked a lot in Go, and I looked up the source for gofmt, 
> seems reasonable.
>
> Anyone willing to mentor, please feel free to contact me, I'd be highly 
> grateful
>
> - Shantanu
>

I'd love to see a tool like that, hope you'll get in!

[julia-users] Re: Core.Core.Core.Core...

[Job van der Zwan]

And here I was thinking that we finally had definite proof linking Stefan 
Karpinski's viking hat to a certain sketch from a certain British comedy 
troupe...

On Wednesday, 18 December 2013 12:39:56 UTC+1, Ivar Nesje wrote:
>
> I think this is unintentional artifact because we can access the 
> namespaced properties inside a module. If you are in a module Mymodule that 
> has a function foo you can either use foo() or MyModule.foo(). That way 
> MyModule must be one of the names accessible inside MyModule.
>
> Maybe others have more insight to complement my guess.
>
> Ivar
>
> kl. 12:23:04 UTC+1 onsdag 18. desember 2013 skrev John Grogan følgende:
>>
>> If you fire up julia repl, and type
>>
>>   Core.
>>
>> you get tab completion of the Core module. One of the components is also 
>> called Core., so doing more tab completion...
>>
>>   Core.Core.
>>
>> Gives tab completion of the Core module, but with the path Core.Core.
>>
>> And it continues recursively
>>
>>   Core.Core.Core.
>>
>> I started yesterday and I'm still going...
>>
>> This also happens with user defined packages/modules, and using these 
>> recursive path lists work, but on using, it defaults to the top level. 
>>
>> eg
>>
>>   using Pkg.Pkg.Pgk.Pkg
>>   x = Pkg.myfunction(123)
>>
>> Anyway, I'm wondering if anyone can offer up the reason for this 
>> recursive behaviour?
>>
>> Thanks
>> John
>>
>>

Re: [julia-users] Julia and Python languages

[Job van der Zwan]

Depends on what you mean with legibility. 

For example (and not at all related to x.f(y) vs f(x, y)), if I look at my 
experience with the Go programming language, once you get used to its 
imposed One True Way of formatting it really makes reading other people's 
source code a lot easier. And talking about spending energy on the subject 
of legibility: setting up my editor to use go-fmt (the autoformatting tool) 
when building/saving code means I don't have to spend any time thinking 
about it when writing my own code either; it will automatically get fixed.

It's one of those things the Go developers are very enthusiastic about, and 
at first you go "really? *That's* a killer feature?" but after using it you 
do start to miss it in other languages.

Speaking of which, is there an autoformatting tool for Julia?

That might seem like a tiny thing, but those two things add up.
On Wednesday, 8 January 2014 23:58:19 UTC+1, Daniel Carrera wrote:
>
> I don't know... is legibility a "real" advantage? A lot of the energy 
> spent in designing languages goes into making them feel natural or 
> clear in some sense. People have different views on what that means, 
> and so languages proliferate. Although I do not use OOP, I would not 
> dis anyone for wanting to write code in the form Subject+Verb+Object. 
> I think it is legitimate for someone to argue that this feels more 
> natural. For some kinds of problems I might even agree. 
>
> Cheers, 
> Daniel. 
>
>
> On 8 January 2014 17:19, John Myles White > 
> wrote: 
> > I agree that it’s not a “real” advantage, but, in my experience, the 
> intensity of people’s passion for a feature is often inversely proportional 
> to its computational importance. 
> > 
> > The “has a” relation problem is very close to the issue of delegation 
> that’s come a bunch of times before. At some point I think we have to come 
> up with a solution to this problem. 
> > 
> >  — John 
> > 
> > On Jan 8, 2014, at 8:05 AM, Tobias Knopp 
> > > 
> wrote: 
> > 
> >> Well, I mean some "real" advantages beyond this small syntactical 
> difference. In C++ there is a lot of mix between class methods and regular 
> functions and it is good practice to only use class methods if this is 
> really necessary, i.e. if access to private members is required. 
> >> 
> >> One issue Julia seem to have is that it is not possible to subclass 
> final types. This can be solved by turning the "is a" into a "has a" 
> relation but currently there seem to be no way to carry over all generic 
> methods from the member to the parent type. 
> >> 
> >> Am Mittwoch, 8. Januar 2014 16:47:50 UTC+1 schrieb John Myles White: 
> >> I think part of the appeal of dot-notation OO is that it reads 
> left-to-right, which helps to make the code seem to read in the same order 
> as the sequence of actions taken. 
> >> 
> >>  — John 
> >> 
> >> On Jan 8, 2014, at 7:45 AM, Tobias Knopp  
> wrote: 
> >> 
> >> > Would be interesting to see some use cases where "Java-like" OO 
> better fits than Julias OO. In C++ one can use both and usually choses 
> based on whether the dispatching can be done at runtime or at compile time 
> (i.e. classes with virtual function for runtime decisions and templates for 
> compile time decisions). 
> >> > There are many situations where I would have liked to use generic 
> programming in C++ but it was not possible as the type was only known at 
> runtime. In Julia this is no issue which makes it such a joy to use. 
> >> > 
> >> > 
> >> > Am Mittwoch, 8. Januar 2014 14:17:20 UTC+1 schrieb Stefan Karpinski: 
> >> > It's a bit hard to say whether Julia is object-oriented or not. I 
> suspect that for a lot of people, object-oriented means "do you write 
> `x.f(y)` a lot?" By that metric, Julia is not very object oriented. On the 
> other hand, everything you can do with single-dispatch o.o. in C++ or Java, 
> you can easily simulate with multiple dispatch, but you'll have to get used 
> to writing `f(x,y)` instead of `x.f(y)`. If your notion of 
> object-orientation has more to do with encapsulation and/or message 
> passing, then we start to look pretty non-o.o. again. 
> >> > 
> >> > 
> >> > On Wed, Jan 8, 2014 at 5:25 AM, Matthias BUSSONNIER <
> bussonnie...@gmail.com> wrote: 
> >> > 
> >> > Le 7 janv. 2014 à 21:48, Erik Engheim a écrit : 
> >> > 
> >> >> Thanks for the nice comments all of you. I guess I have to keep 
> writing more about my Julia experiences after this ;-) 
> >> >> 
> >> >> On Tuesday, January 7, 2014 9:39:05 PM UTC+1, Ivar Nesje wrote: 
> >> >> Great post, it sums up very well the things I think is the strengths 
> of Julia. 
> >> >> 
> >> >> A few notes: 
> >> >> Julia does not look up the method at runtime if the types of the 
> arguments to the function can be deduced from the types of the arguments to 
> the surrounding function (but it behaves that way for the user, unless he 
> redefines the method after the function was compiled #265). 
> >> >> 
> >> >> 
> >> >> That is coo

Re: [julia-users] Julia and Python languages

[Job van der Zwan]

The problem I see with that is that you can wait for a *very* long time 
before any consensus emerges. There are simply many choices to be made in 
that regard which at the end of the day are kind of arbitrary - that *a*choice 
is made and consistently followed is more important, and again the 
benefit of autoformatting is that you don't have to waste putting effort 
into doing so.

Having something something concrete to respond to also helps with the 
discussion - an autoformatting tool will impose a certain style, which will 
drive the discussion of standardising proper style. If people disagree with 
the formatting it provides, great! That means a discussion is triggered.

So instead of waiting for a consensus to emerge, I think that building an 
autoformatting tool with a "good enough first guess" in terms of style 
would be the place to start. Even if it starts out with terrible style 
choices otherwise.

(is this worth starting a separate discussion on the topic?)

On Thursday, 9 January 2014 03:18:05 UTC+1, John Myles White wrote:
>
> There is not yet, because there is still not a consensus on proper style. 
> Hopefully once we have that, it will be easier to make a julia fmt tool. 
>
>  — John 
>
> On Jan 8, 2014, at 6:09 PM, Job van der Zwan 
> > 
> wrote: 
>
> > Depends on what you mean with legibility. 
> > 
> > For example (and not at all related to x.f(y) vs f(x, y)), if I look at 
> my experience with the Go programming language, once you get used to its 
> imposed One True Way of formatting it really makes reading other people's 
> source code a lot easier. And talking about spending energy on the subject 
> of legibility: setting up my editor to use go-fmt (the autoformatting tool) 
> when building/saving code means I don't have to spend any time thinking 
> about it when writing my own code either; it will automatically get fixed. 
> > 
> > It's one of those things the Go developers are very enthusiastic about, 
> and at first you go "really? That's a killer feature?" but after using it 
> you do start to miss it in other languages. 
> > 
> > Speaking of which, is there an autoformatting tool for Julia? 
>

[julia-users] Autoformatting for Julia?

[Job van der Zwan]

So you are saying that the most of the tooling required for an 
auto-formatting tool is already there?

On Thursday, 9 January 2014 14:42:40 UTC+1, Stefan Karpinski wrote:
>
> I would be into having an auto-formatting tool. The way to do this would 
> be to work on the printing of ASTs until the way the code prints is the 
> standard way it should be formatted. Then you have an auto-formatter: parse 
> the code and print the resulting AST. One missing thing is that parser 
> currently discards comments.
>
>
> On Thu, Jan 9, 2014 at 6:48 AM, Job van der Zwan 
> 
> > wrote:
>
>> The problem I see with that is that you can wait for a *very* long time 
>> before any consensus emerges. There are simply many choices to be made in 
>> that regard which at the end of the day are kind of arbitrary - that 
>> *a*choice is made and consistently followed is more important, and again the 
>> benefit of autoformatting is that you don't have to waste putting effort 
>> into doing so.
>>
>> Having something something concrete to respond to also helps with the 
>> discussion - an autoformatting tool will impose a certain style, which will 
>> drive the discussion of standardising proper style. If people disagree with 
>> the formatting it provides, great! That means a discussion is triggered.
>>
>> So instead of waiting for a consensus to emerge, I think that building an 
>> autoformatting tool with a "good enough first guess" in terms of style 
>> would be the place to start. Even if it starts out with terrible style 
>> choices otherwise.
>>
>> (is this worth starting a separate discussion on the topic?)
>>
>>
>> On Thursday, 9 January 2014 03:18:05 UTC+1, John Myles White wrote:
>>
>>> There is not yet, because there is still not a consensus on proper 
>>> style. Hopefully once we have that, it will be easier to make a julia fmt 
>>> tool. 
>>>
>>>  — John 
>>>
>>> On Jan 8, 2014, at 6:09 PM, Job van der Zwan  
>>> wrote: 
>>>
>>> > Depends on what you mean with legibility. 
>>> > 
>>> > For example (and not at all related to x.f(y) vs f(x, y)), if I look 
>>> at my experience with the Go programming language, once you get used to its 
>>> imposed One True Way of formatting it really makes reading other people's 
>>> source code a lot easier. And talking about spending energy on the subject 
>>> of legibility: setting up my editor to use go-fmt (the autoformatting tool) 
>>> when building/saving code means I don't have to spend any time thinking 
>>> about it when writing my own code either; it will automatically get fixed. 
>>> > 
>>> > It's one of those things the Go developers are very enthusiastic 
>>> about, and at first you go "really? That's a killer feature?" but after 
>>> using it you do start to miss it in other languages. 
>>> > 
>>> > Speaking of which, is there an autoformatting tool for Julia? 
>>>
>>
>

Re: [julia-users] Julia computational efficiency vs C vs Java vs Python vs Cython

[Job van der Zwan]

I must say, I'm really surprised that adding two Int32 variables results in 
an Int64 - I naively assumed Julia to work like this:

a::T
b::T
(a+b)::T

If people explicitly type a variable as an 32 bit integer, I think it's 
safe to assume they want to keep it that way unless there is no other 
option - like some kind of "principle of least promotion/conversion."

On Thursday, 16 January 2014 14:41:32 UTC+1, Stefan Karpinski wrote:
>
> On Thu, Jan 16, 2014 at 1:39 AM, Tobias Knopp 
> 
> > wrote:
>
>> But why isn't float32 promoting to float64 on basic arithmetics then? 
>>
>
> Well, it used to. But there were enough people who really wanted to use 
> Float32 arithmetic, so we changed it. The squeaky wheel gets oiled.
>
> As Markus pointed out, when we get SIMD support (in the form of the @simd 
>> macro or by autovectorization of llvm) there can be a factor of two between 
>> both integer computations.
>>
>
>  This is a very legitimate concern, and we may have to revisit this 
> decision.
>

Re: [julia-users] Julia computational efficiency vs C vs Java vs Python vs Cython

[Job van der Zwan]

On Wednesday, 22 January 2014 02:17:36 UTC+1, Ivan Tong wrote:
>
> I think the greedy solution is both behaviors? =D
>
>>
Although I get the idea of "let's try to please everyone", I think that it 
will just lead to confusion and hard to find bugs in this particular case. 

[julia-users] Re: Google Summer of Code: Your Project Suggestions

[Job van der Zwan]

Developing an autoformatting tool? Like I said earlier in another 
discussion, I really miss gofmt when not programming in Go these days. But 
there's more to it than simple convenience.

To quote Andrew Gerrand's argumentsin 
favour of having one standard tool for this (he was discussing gofmt):

>
>- easier to *write*: never worry about minor formatting concerns while 
>hacking away,
>- easier to *read*: when all code looks the same you need not mentally 
>convert others' formatting style into something you can understand.
>- easier to *maintain*: mechanical changes to the source don't cause 
>unrelated changes to the file's formatting; diffs show only the real 
>changes.
>- *uncontroversial*: never have a debate about spacing or brace 
>position ever again!
>
> Regarding that last point: when I brought up autoformatting tools last 
time, one argument against making one now was that there is no consensus 
yet on a best stye for writing Julia. However, I think this thinking is the 
wrong way round.

Some formatting decisions are inherently arbitrary. It is more important 
that *a* choice is made. That's either a majority-vote or top-down 
decision. Making an autoformatting tool will drive these decisions, rather 
than wait for them to happen on their own (some time after the heat death 
of the universe, if other languages are any indication).

Also highly relevant to a language still in its infancy is that a tool like 
this makes certain breaking changes to the language or standard library 
less painful. See the GoFix tool used in the Go language before it 
stabilised into version 1.0:

Gofix  is a new tool that reduces the amount 
> of effort it takes to update existing code. It reads a program from a 
> source file, looks for uses of old APIs, rewrites them to use the current 
> API, and writes the program back to the file. Not all API changes preserve 
> all the functionality of an old API, so gofix cannot always do a perfect 
> job. When gofix cannot rewrite a use of an old API, it prints a warning 
> giving the file name and line number of the use, so that a developer can 
> examine and rewrite the code. Gofix takes care of the easy, repetitive, 
> tedious changes, so that a developer can focus on the ones that truly merit 
> attention. Each time we make a significant API change we’ll add code to 
> gofix to take care of the conversion, as much as mechanically possible. 
> When you update to a new Go release and your code no longer builds, just 
> run gofix on your source directory. 
>
http://blog.golang.org/introducing-gofix

Having a tool like that would surely help with the adoption of Julia, as it 
would reduce fears of code breaking all the time. Also, it would let the 
developers of the language make more drastic changes for a longer time, as 
they would not have to worry as much about breaking existing code out there.

On Sunday, 16 February 2014 19:50:06 UTC+1, Mike Innes wrote:
>
> We've published a project ideas list for GSoC here:
>
> http://julialang.org/gsoc/2014/
>
> We'd like our ideas page to be as healthy and diverse as possible, so 
> please do make your suggestions. Projects can include things like new 
> packages, specific language/package features, or something more 
> experimental; really, there's scope for any kind of coding project here, 
> but those which fit roughly three months of work and have a clear, tangible 
> benefit are best.
>
> If you maintain or use a package which is missing key features, now would 
> be a great time to ask for them!
>
> You're welcome to add project descriptions via github, but if you want to 
> suggest something more informally you can do so here - I'll continue to 
> write up as many as I can.
>
> Thanks,
> Mike
>
>

Re: [julia-users] Re: Google Summer of Code: Your Project Suggestions

[Job van der Zwan]

On Monday, 17 February 2014 17:56:39 UTC+1, Stefan Karpinski wrote:
>
> I'm actually quite sympathetic to this idea. I suspect that Jeff thinks 
> it's a bit of a waste of time but might be fine with using one as long as 
> he didn't have to put effort into creating it. My guess is that Viral 
> doesn't really care, and Alan is actively waging a war against spaces, so 
> he might be miffed to have them automatically inserted everywhere ;-)
>

OTOH it will automatically trim off those forgotten half-a-dozen 
spaces/tabs at the end of a line after major code refactoring, so it might 
be worth the trade-off ;-).
 

> This is actually less relevant to Julia than you might think. [reasons why]
>

Now that you mention it, what I enjoyed when reading the Julia manual was 
indeed how minimalist yet "complete" the core language felt. 

Thanks to multiple dispatch, API changes can be easily handled via 
> deprecation. 
>

Still, automated help with refactoring can't be a bad thing for any 
language, right?

On the other hand, since dynamic languages like Julia are inherently hard 
> to statically analyze, we can't handle really API changes at the level of 
> AST transformations like Go can – because you can't in general statically 
> resolve what function a call actually invokes.


Oh, right... darn it.

Off-topic, it's kind of interesting to compare Go and Julia; I like both 
languages, but they couldn't be more different in many of their design 
decisions. Yet those decisions make sense when you look at different the 
problems they are trying to solve.

Re: [julia-users] Re: Julia as a General Purpose Language

[Job van der Zwan]

On Tuesday, 18 February 2014 20:41:37 UTC+1, Stefan Karpinski wrote:
>
> Domain-specific languages (DSLs) are in vogue these days, but personally I 
> believe that we need a few very powerful, general-purpose languages, not a 
> lot of weak, special-purpose ones. I suspect that what drives the DSL 
> school of thought is the idea that we've already pushed linguistic 
> expressiveness and power as far as it can go and it hasn't solved our 
> problems. This appears to suggest that we need to go in the other direction 
> and make more limited and specialized languages. But I believe, instead, 
> that the premise that we've taken programming language expressiveness and 
> power as far as it can go is incorrect. We need to be pushing linguistic 
> power even further, rather than restricting it.
>

I don't think I completely agree with this paragraph (although I don't 
exactly disagree with it either). Yes, we need better general purpose 
languages. But I believe one road to finding the needed innovations for 
that goes through domain specific languages. By trying to solve domain 
specific problems you stumble upon solutions that can be applied more 
generally than the specific problem domain. After all, isn't that part of 
what happened with Julia? Take the numeric work example. Yes, Julia's 
innovations would be great to have in other general purpose languages, but 
didn't the motivation for coming up with it arise from that particular 
problem being more relevant to the specific domain of technical computing?

And to give an example of another innovation motivated by a domain specific 
problem, take a look at Halide (which I admittely have never used but find 
conceptually very interesting)

Using existing programming tools, writing high-performance image processing 
> code requires sacrificing readability, portability, and modularity. We 
> argue that this is a consequence of conflating what computations define the 
> algorithm, with decisions about storage and the order of computation. We 
> refer to these latter two concerns as the schedule, including choices of 
> tiling, fusion, recomputation vs. storage, vectorization, and parallelism. 
>
> We propose a representation for feed-forward imaging pipelines that 
> separates the algorithm from its schedule, enabling high-performance 
> without sacrificing code clarity. This decoupling simplifies the algorithm 
> specification: images and intermediate buffers become functions over an 
> infinite integer domain, with no explicit storage or boundary conditions. 
> Imaging pipelines are compositions of functions. Programmers separately 
> specify scheduling strategies for the various functions composing the 
> algorithm, which allows them to efficiently explore different optimizations 
> without changing the algorithmic code. 
>
http://people.csail.mit.edu/jrk/halide12/
http://halide-lang.org/

Now, I admit that I'm not that educated about programming languages and 
their history, but this idea of decoupling of the algorithm and the 
schedule is very novel to me, and it makes me wonder if that can be used in 
other areas than image pipelines.

Re: [julia-users] Re: The "then" keyword

[Job van der Zwan]

On Friday, 21 March 2014 21:54:53 UTC+1, Stefan Karpinski wrote:
>
> On the other hand, saying "4 == 2 + 2 or go home" is perfectly reasonable 
> ;-)
>

I like the && and || trick - hadn't seen it before and it's quite neat that 
it just happens to work due to the language design! *But* the || was 
actually more confusing than && for me, because the "English" translation 
of it reads like an exclusive or. Which it isn't. Except that it works like 
one because of short-circuiting. It confuses in a way not unlike using 
double negation.

So for the sake of people who just are starting out and still have to get 
used to this Boolean logic thing, if the documentation is going to mention 
this trick, I think it's very important that it very clearly explains how 
and why it works. Because you don't want people to walk away with a 
half-assed understanding of what's going on.

To play the devil's advocate some more: if-statements that start as 
one-liners tend to expand to do more stuff as the code is updated and grows 
in complexity. Go, for example, has mandatory curly braces around if 
statements for this reason: to avoid ambiguity and leave less room for 
mistakes when updating the code later. This could be an argument against 
the proposed "then" keyword for one-liners.

[julia-users] Re: new REPL

[Job van der Zwan]

On Saturday, 29 March 2014 20:59:19 UTC+1, Stefan Karpinski wrote:
>
>
>- The new REPL, is pretty clean, simple Julia code. Seriously – terminal 
>support, 
>line 
> editing, 
>and the REPL 
> itselfare less 
> than 2000 lines of code – 
>*total*. This works out to a net code reduction of 33233 lines of code 
>(GNU readline is 34640 lines of C), while *gaining* functionality. 
>That has to be a project record. 
>- The new code is infinitely easier to modify, fix and improve, so 
>REPL-replated bugs will probably get fixed lickety split going forward.
>
>  TIL infinity is approximately 33/2. Seriously though, that's amazing. 
Well done guys!

Re: [julia-users] Re: new REPL

[Job van der Zwan]

Still more accurate than most approximations used in astronomy ;)

On Monday, 31 March 2014 14:38:48 UTC+2, Stefan Karpinski wrote:
>
> Hey, in networking protocols, infinity is often 15.
>
> On Mar 31, 2014, at 7:58 AM, Job van der Zwan 
> > 
> wrote:
>
> On Saturday, 29 March 2014 20:59:19 UTC+1, Stefan Karpinski wrote:
>>
>>
>>- The new REPL, is pretty clean, simple Julia code. Seriously – terminal 
>>
>> support<https://github.com/JuliaLang/julia/blob/master/base/Terminals.jl>, 
>>line 
>> editing<https://github.com/JuliaLang/julia/blob/master/base/LineEdit.jl>, 
>>and the REPL 
>> itself<https://github.com/JuliaLang/julia/blob/master/base/REPL.jl>are less 
>> than 2000 lines of code – 
>>*total*. This works out to a net code reduction of 33233 lines of 
>>code (GNU readline is 34640 lines of C), while *gaining*functionality. 
>> That has to be a project record. 
>>- The new code is infinitely easier to modify, fix and improve, so 
>>REPL-replated bugs will probably get fixed lickety split going forward.
>>
>>  TIL infinity is approximately 33/2. Seriously though, that's amazing. 
> Well done guys!
>
>

[julia-users] Re: ANN: TestImages

[Job van der Zwan]

Great, now we have all we need to implement LenPEG!

http://www.dangermouse.net/esoteric/lenpeg.html

On Thursday, 3 April 2014 00:07:57 UTC+2, Tim Holy wrote:
>
> It's a very simple package: it provides an easy way to load images that 
> have 
> become something of a standard in the image processing community. 
>
> https://github.com/timholy/TestImages.jl 
>
> If there are important ones I've missed, feel free to submit a PR. 
>
> --Tim 
>
>

[julia-users] Re: Fast, robust predicates with Julia

[Job van der Zwan]

On Monday, 12 May 2014 16:21:01 UTC+2, Ariel Keselman wrote:
>
> p.s. I implemented this some time ago (a few years?) using golang, you can 
> see some demo here:
>
> https://www.youtube.com/watch?v=dfx1QA3n2xY&list=UUrqGGYkH7y1W8yH1MbxLXYg
>
> and using Julia it was much more pleasant... of course I still have to do 
> all the Voronoi stuff which is really the hard part
>

Please tell me you got that "Voronoi stuff" you wrote for Go available as a 
library somewhere. Pretty please, with sugar on top. If not, well.. could I 
convince you to implement Adrian Secord's Voronoi Stippling? In a such a 
way that ink coverage and dot resolution is nicely decoupled, so we could 
use a gradient map for the former and the actual image for the latter, for 
example?

http://cs.nyu.edu/~ajsecord/msc_thesis/ajsecord_msc_thesis.pdf

http://cs.nyu.edu/~ajsecord/publications.html

Also, for the sake of your sanity I do hope line 197-287 was generated 
somehow.

[julia-users] Re: Fast, robust predicates with Julia

[Job van der Zwan]

Thank you so much!

I am very busy with other things at the moment, but will dive into the 
code, attempt to update as necessary in a few weeks and share the results, 
if any.

On Monday, 12 May 2014 22:52:17 UTC+2, Ariel Keselman wrote:
>
> Just looked for the code in some old backup drive and found it, see 
> attached. Straight from 2011. Drawing code in Python, Voronoi in Golang 
> (some pre-1 version). It also supports linear gradients within the voronoi, 
> see image below. So code is good but old golang and no docs... sorry for 
> that
>
> Of course most of the math in the gist above is just generated using 
> sympy, as I wrote previously. Now I updated the gist, it contains way less 
> terms and is faster (all by the mat trick of moving the origin). Eventually 
> I want to implement all this in Julia, but it is a lot of work...
>
>
> 
>
>
>
>

[julia-users] Re: JuliaCon Question Thread

[Job van der Zwan]

Are you going to film/livestream it? Are you going to have lightning talks? 
If the answer to both questions is "yes", don't forget to film/stream the 
latter! Apparently the  GopherCon last month had some amazing lightning 
talks but nobody remembered to film them.

On Tuesday, 13 May 2014 05:43:34 UTC+2, Hunter Owens wrote:
>
> Hey All-
>
> As, you (hopefully) know, registration for JuliaCon is 
> now open. 
>
> I'm starting this thread so you can ask me (or any of the other 
> organizers, who are cc'ed) any questions you may have about the conference. 
>
> Please do consider submitting a talk proposal or attending the conference, 
> as we are looking forward to seeing folks in Chicago summer. 
>
> Thanks,
> Hunter
>

[julia-users] Re: GSOC 3D Visualizations plotting API - Make a wish!

[Job van der Zwan]

If we can dream and talk about only tangentially related stuff, I'd love to 
see a fast and easy to use library for making Voronoi diagrams.

On Saturday, 17 May 2014 18:51:37 UTC+2, Simon Danisch wrote:
>
> Hi, 
> I'm currently in the planning phase for my GSOC 3D Visualization project, 
> which also means, that I need to define what the most important 
> visualization forms are.
> I must admit, that I haven't done much plotting myself, so I would have to 
> guess what the really important bits are.
> Instead of slavishly  
> imitating 
> Matlabs plot functions with some mix-ins from my side, I thought we can do 
> better, by getting feedback off the people, that actually plan to use 3D 
> plotting in Julia!
> It would help me a lot, if you could specify what you need exactly in 
> great detail.
> Just tell me what you hate about current solutions, what features you 
> really like, the format of your data, how you like to work, etc...
> Like this, I can find out what needs to be done in order to visualize your 
> data, rate the importance and difficulty and than decide in which order I 
> implement the different plotting capabilities.
> Any feedback, ideas and comments are welcome!
>
> Best wishes,
> Simon
>

Re: [julia-users] Article on `@simd`

[Job van der Zwan]

On Tuesday, 16 September 2014 19:14:16 UTC+2, Jacob Quinn wrote:
>
> Oops, the code I shared had a bug in it
>

Question: if the compiler didn't vectorise despite the @simd macro, is the 
user notified of this? If not, wouldn't that be useful debugging 
information, especially if the message indicated *why*? Aside from helping 
with rewriting code to be properly vectorised, it might even help catch 
general bugs (not everyone would dig into code_llvm output like Jacob did 
here).

Re: [julia-users] Re: a good IDE for Julia ? (Julia Studio does not work with Julia v 0.3.0)

[Job van der Zwan]

Looks like this algorithm, presumably reimplemented in Julia and used to 
generate the image:

http://joco.name/2014/03/02/all-rgb-colors-in-one-image/

On Monday, 29 September 2014 12:41:12 UTC+2, Tim Holy wrote:
>
> Dang, that's an attractive website. Makes me want to try Julia :). 
>
> Is that gorgeous image Yuri's work? 
>
> --Tim 
>
> On Monday, September 29, 2014 03:27:06 AM Viral Shah wrote: 
> > The light table work that Mike Innes has done is now packaged and 
> available 
> > at http://www.junolab.org/ 
> > 
> > We are hoping to work towards making self-sufficient binaries and 
> getting 
> > it to a point where it is usable with a single download. The real fun is 
> to 
> > then try and do more interesting things. I don't know what those are, 
> but I 
> > do feel that we are setting ourselves up with a good base. 
> > 
> > -viral 
> > 
> > On Saturday, September 27, 2014 12:38:39 PM UTC+5:30, 
> colint...@gmail.com 
> > 
> > wrote: 
> > > No, I don't think it has debugging a la the Matlab IDE or R-Studio 
> (yet). 
> > > My understanding is that for now the Debug package is all that is 
> > > available. Personally I make do with sending blocks of code to a 
> console 
> > > in 
> > > Sublime-IJulia (you can do this with shift+enter, just like in 
> R-Studio). 
> > > 
> > > Cheers, 
> > > 
> > > Colin 
> > > 
> > > On Friday, September 26, 2014 7:00:09 PM UTC+10, Ján Dolinský wrote: 
> > >> Hello, 
> > >> 
> > >> I cloned the master branch of Julia Studio and compiled it. I am 
> however 
> > >> getting this error when running ./JuliaStudio : 
> > >> libExtensionSystem.so.1: cannot open shared object file: No such file 
> or 
> > >> directory 
> > >> 
> > >> however when running using ./julia-studio.sh it runs but fails to 
> open a 
> > >> console with the following errors: 
> > >> Error: Failed to start Julia. 
> > >> Expected location: /usr/local/Julia_Studio/julia 
> > >> 
> > >> I am little bit lost here but exploring the Julia Studio menu I 
> assume 
> > >> that it doe not provide debugging capability (I had an impression 
> that it 
> > >> does). 
> > >> 
> > >> Thanks, 
> > >> Jan 
> > >> 
> > >> Dňa piatok, 19. septembra 2014 11:57:47 UTC+2 Uwe Fechner 
> napísal(-a): 
> > >>> I think that this branch is already merged into the master branch: 
> > >>> https://github.com/forio/julia-studio/tree/julia-0.3-compatibility 
> > >>> 
> > >>> On Friday, September 19, 2014 11:54:41 AM UTC+2, Uwe Fechner wrote: 
> >  If you compile Julia Studio from source it should work with Julia 
> 0.3. 
> >  See: 
> >  https://github.com/forio/julia-studio/issues/241 
> >  
> >  Regards: 
> >  
> >  Uwe 
> >  
> >  On Friday, September 19, 2014 10:58:26 AM UTC+2, Ján Dolinský 
> wrote: 
> > > Hello guys, 
> > > 
> > > After upgrading to Julia 0.3.0 Julia Studio stopped working (I 
> changed 
> > > the symbolic links in Julia Studio directory but nevertheless 
> ...). 
> > > Can 
> > > somebody suggest any workaround ? Is it true that Julia Studio 
> will 
> > > not 
> > > support newer versions of Julia ? 
> > > What are you guys using now ? 
> > > 
> > > Thanks a lot, 
> > > Jan 
>
>

[julia-users] Re: ANN: GeometricalPredicates.jl

[Job van der Zwan]

On Thursday, 9 October 2014 21:34:21 UTC+2, Ariel Keselman wrote:
>
> This is used in a Delaunay/Voronoi implementation which I'll also package 
> which is faster than CGAL.
>
>
Any updates on this? Also, would it support weighted voronoi maps?

[julia-users] Re: ANN: GeometricalPredicates.jl

[Job van der Zwan]

Fantastic! 

Question: how does the algorithm that you used compare to Fortune's 
algorithm in the 2D case? 

By the way, since we're on the topic of Voronoi diagrams: I happened across 
this 
algorithm  
for quickly computing Voronoi treemaps by Arlind Nocaj and Ulrik Brandes. 
Java implementation here 
, JavaScript 
version here . Might make a 
cool plotting addition?


On Monday, 13 October 2014 22:47:26 UTC+2, Ariel Keselman wrote:
>
> The Delaunay/Voronoi package is almost ready. All functionality is in 
> place, in a few days I'll publish (when I manage to write some basic 
> documentation and better tests)
>
> Weighted Voronoi is definitely in the todo list :)
>
> See attached image created with this package, and this post 
>  for some more info
>
>
> 
>
>

[julia-users] Re: ANN: GeometricalPredicates.jl

[Job van der Zwan]

On Tuesday, 14 October 2014 14:44:06 UTC+2, Ariel Keselman wrote:
>
> *A comparison with Fortune's algorithm - *the Julia implementation is 
> somewhat faster than CGAL, and CGAL is faster than Boost Voronoi which uses 
> Fortune's algorithm, see here: 
> http://www.boost.org/doc/libs/1_56_0/libs/polygon/doc/voronoi_benchmark.htm
>
 
I'm officially hyped.

[julia-users] Re: ANN: GeometricalPredicates.jl

[Job van der Zwan]

On Tuesday, 14 October 2014 14:44:06 UTC+2, Ariel Keselman wrote:
>
> *Treemaps -* I agree it is a very nice plotting addition, it can be 
> implemented once we have weighted generators. It should belong to a 
> different package though...
>

Oh certainly, just thought I'd share.

BTW, near the end of the linked paper the authors also a nice little 
speedup heuristic for Lloyd's algorithm when using weighted generators - 
they claim it has about 70% faster convergence.

[julia-users] Re: Full blown GUI programming with Julia+JS

[Job van der Zwan]

On Wednesday, 5 November 2014 18:16:18 UTC+1, Viral Shah wrote:
>
> SVG document
>

Wait, does that mean that the best browser for this is a recent version of 
*Internet 
Explorer?!*

At least, last time I checked (admittedly, quite a while ago) it had the 
best SVG support and performance.

Re: [julia-users] Full blown GUI programming with Julia+JS

[Job van der Zwan]

>
> What's best is relative ;-) I personally haven't used IE in years, so I 
> wouldn't know.
>
Of course ;). For the record, neither have I (which would explain my 
outdated info, see below)

On Thursday, 6 November 2014 20:23:46 UTC+1, Jameson wrote:
>
> Completely OT and [citation needed]. However, fwiw, IE didn't add SVG 
> support until IE9
>

Sorry, sorry. I was just joking because I remember IE being the first to 
support hardware accelerated SVG and surprising everyone by beating the 
other browsers in this department [0]. My own tests at the time had similar 
results. But that was a lot of versions ago, if I run some more recent 
benchmarks[1][2], they're much closer. On Windows, that is -IIRC Firefox 
doesn't have hardware acceleration on Linux yet, for example.

Anyway, the only real issue seems to be that SVG still still doesn't scale 
very well[3] (in terms of elements, not resolution of course), so as long 
as you don't have too many GUI elements it shouldn't matter much.

[0] http://joeloughton.com/blog/web-applications/svg-vs-canvas-performance/ 
[1] http://jsperf.com/html-vs-svg-vs-canvas/26 (FF beats Chrome beats IE on 
my machine)
[2] https://www.mapbox.com/osmdev/2012/11/20/getting-serious-about-svg/ - 
(check the unrounded/rounded performance links, Chrome beats IE beats FF on 
my machine)
[3] http://frozeman.de/blog/2013/08/why-is-svg-so-slow/

[julia-users] Re: Great new expository article about Julia by the core developers

[Job van der Zwan]

Is this the proper thread to send in found minor typos? Page 15: 

"If x and y are not both real or not both complex, then g(x,y) is an 
error." 

I'm pretty sure that should be f(x,y)instead.

Also, on the same page it is said that single static dispatch isn't done in 
practice, but Go takes a stance against function overloading[1]. Doesn't 
that make it an example of single static dispatch?

[1] http://golang.org/doc/faq#overloading

On Monday, 10 November 2014 04:55:09 UTC+1, Waldir Pimenta wrote:
>
> Link to the arXiv page (the pdf version linked below is obsolete, there's 
> a new revision up): http://arxiv.org/abs/1411.1607
>
> Also, I found a typo: in "...which sorts by radius than angle", it should 
> be "then", not "than".
>

[julia-users] Re: Great new expository article about Julia by the core developers

[Job van der Zwan]

Also (still page 15) section 4.2: *Number/Function “*11 *misses the closing 
quotes

(I hope it's obvious I find this an enjoyable read in general, just trying 
to help out with the editing)

Re: [julia-users] Re: home page content

[Job van der Zwan]

My two cents:

   - Plots are great, but please make them readable for the colourblind - 
   use triangles/squares/etc in addition to circles, use lightness and 
   saturation on top of hue. I can't make sense of the linked examples so far.
   - Code widgets are probably not that interesting outside of tutorial 
   pages, but an online sandbox is fantastic for discussing short snippets of 
   code. For example, play.golang.org is basically a runnable gist, and it 
   is constantly used in online discussions like *how to do x* or *why 
   doesn't y compile*?
   

Re: [julia-users] Rust and Julia - Together? Advice

[Job van der Zwan]

On Thursday, 18 December 2014 16:58:59 UTC+1, Eric Forgy wrote:
>
> I miraculously figured out how to use ZMQ in Julia, i.e. you type "using 
> ZMQ" :)
>
 
Well, the developers did say they want Julia to have all the good bits of 
Python 

[julia-users] Andrei Alexandrescu demonstrates a generic sentinel+"vacancy" optimisation method; relevant for speeding up algorithms in Julia?

[Job van der Zwan]

For those unfamiliar with sentinel values 
, think "zero terminated 
string" instead of "knowing the length of the string and checking if you 
are inbound every step" - the former removes a comparison, because 
termination can become part of the character lookup.

Andrei Alexandrescu just gave a keynote about this very old technique. One 
thing to note was his claim that while this can be a very effective 
technique, it is not used in generics often, due to a lack of introspection 
capabilities in most programming languages. Enter Julia?

It's a long presentation (albeit an entertaining one, as Alexandrescu's 
presentation tend to be) and there is no transcript yet AFAIK, so I'll also 
link directly to different parts:

   - Slideshare upload of the presentation slides
   
   

   - Youtube upload of the presentation  
   (total time: 1h06m).
   - 10m28s : 
  reintroduction to sentinels, and how to get sentinel guards in generic 
code 
  with introspection. Uses Linear Find as an example
  - 29m04s : 
  sentinels in Tony Hoare's partitioning
  - 37m54s : 
  new-ish trick: creating a vacancy in the range to reduce full swaps to 
  half-swaps:
 - put sentinels at both ends
 - remove pivot value to create a "vacancy" in the range: an empty 
 slot in the range to move a value to
 - break swap into two assignments
- a swap fills one vacancy and leaves another to be filled in 
from the other side
- turns swaps into half-swaps, no need for temporary values!
 - at the end fill in the vacancy with removed value
 - cleanup
  - 49m13s : 
  claims of this trick being generalisable to many situations:
 - Dot product
 - Set intersection
 - Merging sorted lists
 - Lexing and parsing
 
Given that at least three of these example are things I expect Julia does a 
lot, and that there might be more places this is effective, I figured this 
might be relevant to your interests.

Then again, for all I know this is a trick the Julia team is already 
employing everywhere that it makes sense :P

(Found on /r/programming 
,
 see 
comments there )

[julia-users] Andrei Alexandrescu demonstrates a generic sentinel+"vacancy" optimisation method; relevant for speeding up algorithms in Julia?

[Job van der Zwan]

For those unfamiliar with sentinel values 
, think "zero terminated 
string" instead of "knowing the length of the string and checking if you 
are inbound every step" - the former removes a comparison, because 
termination can become part of the character lookup.

Andrei Alexandrescu just gave a keynote about this very old technique. One 
thing to note was his claim that while this can be a very effective 
technique, it is not used in generics often, due to a lack of introspection 
capabilities in most programming languages. Enter Julia?

It's a long presentation (albeit an entertaining one, as Alexandrescu's 
presentation tend to be) and there is no transcript yet AFAIK, so I'll also 
link directly to different parts:

   - Slideshare upload of the presentation slides
   
   

   - Youtube upload of the presentation  
   (total time: 1h06m).
   - 10m28s : 
  reintroduction to sentinels, and how to get sentinel guards in generic 
code 
  with introspection. Uses Linear Find as an example
  - 29m04s : 
  sentinels in Tony Hoare's partitioning
  - 37m54s : 
  new-ish trick: creating a vacancy in the range to reduce full swaps to 
  half-swaps:
 - put sentinels at both ends
 - remove pivot value to create a "vacancy" in the range: an empty 
 slot in the range to move a value to
 - break swap into two assignments
- a swap fills one vacancy and leaves another to be filled in 
from the other side
- turns swaps into half-swaps, no need for temporary values!
 - at the end fill in the vacancy with removed value
 - cleanup
  - 49m13s : 
  claims of this trick being generalisable to many situations:
 - Dot product
 - Set intersection
 - Merging sorted lists
 - Lexing and parsing
 
Given that at least three of these example are things I expect Julia does a 
lot, and that there might be more places this is effective, I figured this 
might be relevant to your interests.

Then again, for all I know this is a trick the Julia team is already 
employing everywhere that it makes sense :P

(Found on /r/programming 
,
 see 
comments there )

[julia-users] What packages, features, other strengths would you recommend when showing Julia to molecular neurobiologists?

[Job van der Zwan]

*TLDR: I'd like to show Julia to my colleagues, but don't have a clue which 
cool packages and features I should show off to them, because I don't do 
any scientific work myself.*

Hi,

I'm an interaction designer working for a research group at Karolinska 
Institute[0]. Basically, I'm a glorified front-end webdev. I don't do any 
scientific work myself, I'm just building a web-based interface for 
browsing and visualizing single-cell data for them. So my use-cases don't 
seem to align with Julia's strengths, but I like the design of the 
language, the ideas behind the project and have been following its 
development great pleasure.

Last week while watching a bunch of JuliaCon videos during a lunch break, 
one of my colleagues asked what the video was about. I tried to explain the 
Julia project to him, as well as the language's strengths and weaknesses. 
Sadly, I didn't really do a good job of it, since I don't actually program 
in it myself. He said it looked a lot like Matlab (his language of choice) 
and was interested in the free-and-open-source aspect. But he expected 
there to not be enough packages yet for him to work with it and was 
sceptical about whether switching to it would be worth it. I tried to 
explain that Julia can call out to Matlab code with practically no 
overhead, but he didn't really look convinced (and I didn't have a working 
Julia environment to show it off to him either). While Jupyter was also a 
turn-off, since he doesn't like notebooks, but the Juno video compensated 
for that a lot.

Basically, I'd like to show Julia to my colleagues, give them some pointers 
on where it might be fun to start playing with it, what are some of its 
amazing features *that matter to them*, but I don't have a clue of what I 
should focus on to do so.

The researchers I work for are molecular neurobiologists. They're doing 
pretty well, having published in Science last year and this year, see 
here[1] for a list of publicatiosn. Currently Anaconda is the "lingua 
franca" platform, but some in the group prefer Matlab or R over Python. Of 
course, one of Julia's selling points is that it's a very "inclusive" 
language, so I definitely could show that, but I don't know what else to 
demonstrate. I'm hoping there are researchers here with similar enough 
use-cases for Julia who could give me some suggestions about what kind of 
things they might really like over their existing solutions.

Cheers,
Job

[0] http://linnarssonlab.org/
[1] http://linnarssonlab.org/publications/

Re: [julia-users] Re: What packages, features, other strengths would you recommend when showing Julia to molecular neurobiologists?

[Job van der Zwan]

@Chris: thanks for the tips!

@Tamas: oh I know what you mean, and don't worry, I'm definitely not 
planning on telling these people how they should do their research! But as 
a counterpoint: they also are so focused and busy dealing with their 
research problems that they don't really have the time to leisurely explore 
what Julia has to offer them (like in that cartoon with square wheels[0], 
although I find that one a bit condescending). Surely it wont hurt doing 
some prep-work for them by finding relevant examples, like Stefan suggests, 
and let them evaluate if it's worth their time.

@Stefan: one example of programming-related struggle within the group is 
that one of them works best in matlab, and he created new clustering 
algorithm called BackSPIN. Then another member of the group ported it to 
Python to make it more widely accessible[1]. But now the first guy has come 
up with an improvement for his algorithm, but the resulting matlab code is 
so complex that the second guy is struggling with porting it. Meanwhile, my 
sole contribution to the whole thing is making sure NumPy's in-place 
methods are used everywhere, and replacing a scalar matrix division with a 
one-over-scalar multiplication in the innermost loop, speeding it up by 
40%. All of which required no understanding of the algorithm.

Anyway, the professor pushed for the whole group to switch to Python to 
prevent exactly this this problem. So now a new member of the team has to 
learn Python because his main language so far is R.

I was thinking that perhaps Julia as a language (plus PyCall, RCall and 
MATLAB.jl) would provide a more appealing compromise for them. What's 
appealing about it to me is that would be easier for me to contribute 
dumb-but-effective low-level optimisations while they work out better 
high-level algorithms.

[0] 
https://hakanforss.files.wordpress.com/2014/03/are-you-too-busy-to-improve2.png
[1] https://github.com/linnarsson-lab/BackSPIN

[julia-users] Re: ANN: Julia v0.4.0 released!

[Job van der Zwan]

Congratulations! That's a lot of changes.

>
>- A major focus of 0.5 will be further* (breaking)* improvements to 
>core array functionality, as detailed in this issue 
>.
>
> I love how you are not afraid to keep tinkering and breaking stuff to fix 
things.

To the people who contributed to all of this: what feature or change that 
you really wanted didn't make it, and what feature or change that did makes 
you super excited?

>
>
>

[julia-users] [General Interest] An update to John Gustafson's Unums: "Unums 2.0"

[Job van der Zwan]

Originally found on: D-lang forum discussion 
, 
forwarded to me by Robbert van Dalen. 


The previous julia-users discussion about unums 
 provoked 
a lot of responses (as did the previous discussion on /r/compsci 
,
 
the previous Hacker News discussion 
), so I figured I'd post this 
as an update for the people who were interested back then. For those of you 
who haven't heard of this before, John Gustafson has been working on an 
alternative number encoding to IEEE floating point. He just presented an 
updated version of this unum proposal at Multicore 2016. It's very 
different from before:

For those of you who think you have already seen unums, this is a different 
approach. Every one of the slides here is completely new and has not been 
presented before the Multicore 2016 conference.

The original unums had sign, exponent, and fraction fields just like IEEE 
floats and obeying most of the same rules; those unums had three metadata 
fields, the “utag”, that described the exact-inexact state, the exponent 
size, and the fraction size, and they therefore had variable length. This 
new approach makes a complete break from IEEE float compatibility and 
redesigns the way we represent the infinite space of real numbers on a 
computer.

They are just as mathematically rigorous as before, but they clear up the 
remaining clunkiness of the IEEE format. They are so terse and so fast that 
you can think about solving very difficult equations by trying the entire 
real number line, overlooking nothing.

You can find all the slides here:

PDF: A Radical Approach to Computation with Real Numbers 


PPTX: A Radical Approach to Computation with Real Numbers 



I recommend the powerpoint, because it has speaker notes (which is where I 
took the above citations from), clarifying a lot.

Gustafson also gave two replies to questions on the D-lang discussion board:


What I don't get is: is there an exposant anymore? I don't see any mention of 
it.
> That's part of the breakthrough: the separation of bit fields that is so 
> deeply built into IEEE floats, has far more drawbacks then advantages. That's 
> where all the problems with gradual underflow, wasted bit patterns on NaNs, 
> hidden bits, and wasted bit patterns in general, stem from. It is possible to 
> extract the exponent, in the traditional sense, by an integer divide if the 
> lattice is one chosen to be self-similar as the dynamic range increases. The 
> integer divide need NOT be by a power of 2, nor do you need to do the divide 
> very often at all... think different about the way we represent reals with 
> bit strings!


The basic idea for Unums seems that you get an estimate of the bounds and then 
recompute using higher precision or better algorithm when necessary. With 
regular floats you just get a noisy value and you need much more heavy 
machinery to know whether you need to recompute using a better algorithm/higher 
precision.
> Not quite. What you describe is a very old idea. When unums lose accuracy, 
> they become multiple unums in a row, or in a multidimensional volume 
> (uboxes). The next calculation starts not from the "interval" described by 
> the largest and smallest unum, but from each unum in the set; the results are 
> then combined as a set union, which leads to bounds that grow linearly 
> instead of exponentially.


PS: Robbert has opened up a Google Group for general Unum computing 
discussion 

[julia-users] Re: [ANN] GLVisualize

[Job van der Zwan]

On Saturday, 27 February 2016 14:46:56 UTC+1, Simon Danisch wrote:
>
> Thanks :)
>
> >I wonder if it will be the Matplotlib of Julia
>
> While possible, it will need quite a bit of work :) Offering the 
> flexibility and usability of Matplotlib is no easy task! 
> Right now the strength rather lies in interactivity and easy means to 
> visualize animated and large data sets.
>
> But there could be shortcuts like implementing a backend for Matplotlib 
> first.
>

If not MatplotLib, could this become the Processing (and by extension 
OpenFrameworks, LibCinder) of Julia?

@Alan, I can create one ;)
> Also, as you can see in http://www.glvisualize.com/examples/interactive/ 
> ,
>  
> something similar to @manipulate can be implemented in GLVisualize.
>

Oh, it looks like you partially answered that question already! :P 

[julia-users] Re: [ANN] GLVisualize

[Job van der Zwan]

On Monday, 29 February 2016 16:03:10 UTC+1, Simon Danisch wrote:
>
> > If not MatplotLib, could this become the Processing (and by extension 
> OpenFrameworks, LibCinder) of Julia?
>
> That's definitely more the direction I'd like to take (although with a 
> very different approach).
> I hope that it will enable us to create a nice platform for accelerated 
> data processing in general. With FireRender 
> 
>  as 
> a backend it might also appeal to artists more!
>

I have to say, after years of Processing API indoctrination (which almost 
every other CC framework follows), I didn't quite understand how the 
interactive examples[0 ] 
work. It took me a while to realise all the input is handled by the 
Reactive package (which I wasn't familiar with) - maybe you want to mention 
that in the documentation somehow?

(offtopic: is there a package for capturing live camera feeds? I'd like to 
mess around with slitscanning[1 
][2 
] as my "Hello World" project 
for this package; and it looks like working with volumes is relatively easy[
3 ] in Julia)