Re: [julia-users] create a type for points on n-dimensional simplex
I think you’d need a family of types to do that. You might look at
https://github.com/twadleigh/ImmutableArrays.jl and try to extend it.
— John
On Dec 31, 2013, at 7:13 AM, Christian Groll groll.christian@gmail.com
wrote:
I already know how I could implement this for a given dimensionality. For
example, for the two-dimensional case I can define:
immutable twoDimSimplex
weight1::Float64
weight2::Float64
twoDimPortfolio(x::Float64, y::Float64) = (abs(x+y - 1) 1e-10) ?
error(entries must sum to one) : new(x,y)
end
However, I do not get how I could extend this for the n-dimensional case.
Here, I thought that I would have to use one field which stores a
n-dimensional vector:
immutable nDimSimplex
points::Vector{Float64}
nDimSimplex(x::Vector{Float64}) = (abs(sum(x) - 1) 1e-10) ?
error(entries must sum to one) : new(x)
end
Now, I think that it will not be possible to change the vector that the field
points to. However, the entries of the vector itself still can be changed
without restrictions. Any recommendations?
On Tuesday, 31 December 2013 12:33:57 UTC+1, Tim Holy wrote:
Use an immutable
http://docs.julialang.org/en/release-0.2/manual/types/#immutable-composite-
types
with an inner constructor:
http://docs.julialang.org/en/release-0.2/manual/constructors/#inner-
constructor-methods
You may find the example
http://docs.julialang.org/en/release-0.2/manual/constructors/#case-study-
rational
helpful.
Best,
--Tim
Re: [julia-users] Style Guideline
I would mention that the vast majority of Base Julia, although it's fairly internally consistent, does not follow a lot of these rules. In particular, the whitespace rules and some of the type annotation rules, and for x in vs for x =. I tend to follow rules that require a bit of judgement, but therefore convey some subtle information about the code. *Whitespace.* I don't use spaces when calling functions that are mathy: f(x,y). I do, on the other hand, tend to use spaces when calling non-mathy functions: endswith(str, substr). I think that math expressions should be spaced so that they're readable and I'm not sure that a fixed set of rules does that, although no spaces for tighter operations and spaces for looser operations is the trend. I rely heavily on Matlab precedence of arithmetic versus :. *For loops.* When the right-hand-side is a range like 1:n then I use =. When the r-h-s is an opaque object that we're iterating over, then I use in. Examples: for i = 1:n # blah, blah end for obj in collection # blah, blah, blah end On Tue, Dec 31, 2013 at 10:01 AM, John Myles White johnmyleswh...@gmail.com wrote: One of the things that I really like about working with the Facebook codebase is that all of the code was written to comply with a very thorough internal style guideline. This prevents a lot of useless disagreement about code stylistics and discourages the creation of unreadable code before anything reaches the review stage. In an attempt to emulate that level of thoroughness, I decided to extend the main Julia manual’s style guide by writing my own personal style guideline, which can be found at https://github.com/johnmyleswhite/Style.jl I’d be really interested to know what others think of these rules and what they think is missing. Right now, my guidelines leave a lot of wiggle room. — John
[julia-users] Re: Style Guideline
On Tuesday, December 31, 2013 11:12:44 AM UTC-5, Daniel Carrera wrote: (18)+(19): I disagree. Although I could favour rules like this in a particular project, in many cases I think that adding type annotations just creates syntactic noise and can create a needless limitation I also strongly disagree with the Always explicitly type all arguments to a function rule. Adding an explicit type imposes a severe cost in generality in many cases, since it prevents duck typing. (And duck typing is extremely important in Julia because of the lack of multiple inheritance.) For example, the whole iterator pattern in Julia relies on *not* declaring types. This also came up in the IterativeSolvers.jl package, where explicitly declaring arguments as AbstractArrays prevented one from using other linear-operator objects (supporting op * vector) that lack array-like random access semantics. As I've argued elsewhere (https://groups.google.com/d/msg/julia-users/WOsN9zTOQbg/RgJMnWdx0IoJ), the main reasons to declare an explicit type in Julia are either to disambiguate method dispatch or to prevent unexpected results (*not*MethodError exceptions). In any given case, you should have a clear reason for why you are declaring a type rather than leaving an argument untyped (and you should especially have a reason for using a concrete rather than an abstract type).
Re: [julia-users] Re: Style Guideline
(4) Using both tabs and spaces is a huge problem in a shared codebase. This is probably the only rule in my entire list that I’m actually going to enforce in the code I maintain. IIRC, Python completely forbids mixing these kinds of space characters at the language level. (7) + (8) These rules are part of the official Google style guides for R, which is the language with the most similarity to Julia that’s being used at companies with public facing style guidelines. I think they’re quite sensible rules, which is why I decided to borrow them from published standards. (18) + (19): This is clearly an area of big disagreement in our community. I might pull them out into a suggestions section since I’d really prefer that code submitted to things like DataFrames.jl follow this rule, but don’t want to include a rule that’s going to be a big schism in the community. (22) + (23) + (24): I may take these out as well. I definitely agree that there’s a big difference between performance guidelines and style guidelines, although that line is blurry when you’re trying to keep a codebase written in a consistent style. (31): Comments aren’t PDF’s or HTML or any other language designed for transmitting carefully formatted documents. You don’t get to use images, properly formatted tables, etc. I find diagrams are an essential part of good documentation. I think conflating documents with code leads to documents that are less readable and lots of lines in code that’s not actually worth reading. (35): I might take this one out as well. It’s somewhere on the boundary between a performance tip and a style habit worth developing. — John On Dec 31, 2013, at 11:12 AM, Daniel Carrera dcarr...@gmail.com wrote: Personally, I do not think that a more thorough style guide is necessarily better. That said, I will give you my comments: (4): I like tabs and I use them. (7) + (8): I disagree. Although I generally use comma+space as you say, at times I deviate from that when I feel that doing so will improve the clarity and readability of my code. (18)+(19): I disagree. Although I could favour rules like this in a particular project, in many cases I think that adding type annotations just creates syntactic noise and can create a needless limitation. (22)+(23)+(24): I do not think that performance tips belong in a style guide. You could spend a lot of time writing performance tips and I don't see an obvious reason why the three tips you chose are more important than other performance tips. (31): I partially disagree. I like writing documentation (e.g. tutorial or explaining an algorithm) at the top of the file. I like having the documentation in the same file as the code that it refers to. I do not know what you mean when you say that English documents are more readable when not constrained by the rule of code comments. What rules are those? Also, I rarely want to have a diagram in my documentation because that involves starting a WYSIWYG program like LibreOffice or something like that. I haven't really felt a lot of need for diagrams. (35): This doesn't sound like a style thing either. Advice on the correct way to use a module, or how to maintain precision or avoid round-off errors, do not belong in a style guide. This sort of thing belongs in either the documentation for the module, or on some tutorial about numerical computation. Cheers, Daniel. On Tuesday, 31 December 2013 10:01:23 UTC-5, John Myles White wrote: One of the things that I really like about working with the Facebook codebase is that all of the code was written to comply with a very thorough internal style guideline. This prevents a lot of useless disagreement about code stylistics and discourages the creation of unreadable code before anything reaches the review stage. In an attempt to emulate that level of thoroughness, I decided to extend the main Julia manual’s style guide by writing my own personal style guideline, which can be found at https://github.com/johnmyleswhite/Style.jl I’d be really interested to know what others think of these rules and what they think is missing. Right now, my guidelines leave a lot of wiggle room. — John
Re: [julia-users] Style Guideline
You’re totally right that Base Julia has a very different implicit style guide than I’ve been using. That’s intentional since I find that some of the Base Julia code is a little hard to read at times. I’ve also been bitten by the absence of important type constraints in Base before (think of when show(io) used to have no type information), so I’ve tended towards initially conservative typing until it’s clear that looser typing is needed. I’m not sure there’s much benefit in having rules that involve personal judgement because reasonable people can make different judgements. So I’d rather have no rule at all (and just let things happen as they may) than try to formalize a rule whose application can’t be reliably checked by a linting program. Coming from R, I’m pretty strongly opposed to Matlab's precedence rule for “:”. I find it hard to read and really wish that it hadn't made it impossible for us to match R’s formula syntax. The “:” operator’s precedence is by far the part of Julia that I most dislike (which, of course, is why I’m such a big fan of Julia, since that’s a minor problem to have as your worst quality.) The for loops thing is one where I don’t have strong feelings, but tend to prefer consistency. I see the appeal of using “=“ in some contexts, but find it easier to avoid using different things to express the same concept. — John On Dec 31, 2013, at 10:54 AM, Stefan Karpinski ste...@karpinski.org wrote: I would mention that the vast majority of Base Julia, although it's fairly internally consistent, does not follow a lot of these rules. In particular, the whitespace rules and some of the type annotation rules, and for x in vs for x =. I tend to follow rules that require a bit of judgement, but therefore convey some subtle information about the code. Whitespace. I don't use spaces when calling functions that are mathy: f(x,y). I do, on the other hand, tend to use spaces when calling non-mathy functions: endswith(str, substr). I think that math expressions should be spaced so that they're readable and I'm not sure that a fixed set of rules does that, although no spaces for tighter operations and spaces for looser operations is the trend. I rely heavily on Matlab precedence of arithmetic versus :. For loops. When the right-hand-side is a range like 1:n then I use =. When the r-h-s is an opaque object that we're iterating over, then I use in. Examples: for i = 1:n # blah, blah end for obj in collection # blah, blah, blah end On Tue, Dec 31, 2013 at 10:01 AM, John Myles White johnmyleswh...@gmail.com wrote: One of the things that I really like about working with the Facebook codebase is that all of the code was written to comply with a very thorough internal style guideline. This prevents a lot of useless disagreement about code stylistics and discourages the creation of unreadable code before anything reaches the review stage. In an attempt to emulate that level of thoroughness, I decided to extend the main Julia manual’s style guide by writing my own personal style guideline, which can be found at https://github.com/johnmyleswhite/Style.jl I’d be really interested to know what others think of these rules and what they think is missing. Right now, my guidelines leave a lot of wiggle room. — John
[julia-users] Re: Style Guideline
IMO the main reason for (33) is that Julia presently lacks any local import feature. At least a few languages with module systems add these; see for instance OCaml http://caml.inria.fr/pub/docs/manual-ocaml-4.01/extn.html#sec225 and also Ada, which allows with/use inside of blocks. Is there a reason that a similar feature wouldn't work well with Julia too? -- Brian On Tuesday, December 31, 2013 7:01:23 AM UTC-8, John Myles White wrote: One of the things that I really like about working with the Facebook codebase is that all of the code was written to comply with a very thorough internal style guideline. This prevents a lot of useless disagreement about code stylistics and discourages the creation of unreadable code before anything reaches the review stage. In an attempt to emulate that level of thoroughness, I decided to extend the main Julia manual’s style guide by writing my own personal style guideline, which can be found at https://github.com/johnmyleswhite/Style.jl I’d be really interested to know what others think of these rules and what they think is missing. Right now, my guidelines leave a lot of wiggle room. — John
Re: [julia-users] Re: Style Guideline
I could see a couple of nice uses for having the ability to do block-local imports, but I’m not sure if that would solve the problems that (33) is meant to address, which is that using importall makes it to too easy to accidentally monkey-patch Base and that using import sometimes makes it hard to know the provenance of functions being extended by a module. The latter is way less problematic than the former: single function import has a lot of good use cases, even if it’s a bit too non-local for my taste. It’s only importall that makes things really hard to keep track of. — John On Dec 31, 2013, at 3:54 PM, Brian Rogoff brog...@gmail.com wrote: IMO the main reason for (33) is that Julia presently lacks any local import feature. At least a few languages with module systems add these; see for instance OCaml http://caml.inria.fr/pub/docs/manual-ocaml-4.01/extn.html#sec225 and also Ada, which allows with/use inside of blocks. Is there a reason that a similar feature wouldn't work well with Julia too? -- Brian On Tuesday, December 31, 2013 7:01:23 AM UTC-8, John Myles White wrote: One of the things that I really like about working with the Facebook codebase is that all of the code was written to comply with a very thorough internal style guideline. This prevents a lot of useless disagreement about code stylistics and discourages the creation of unreadable code before anything reaches the review stage. In an attempt to emulate that level of thoroughness, I decided to extend the main Julia manual’s style guide by writing my own personal style guideline, which can be found at https://github.com/johnmyleswhite/Style.jl I’d be really interested to know what others think of these rules and what they think is missing. Right now, my guidelines leave a lot of wiggle room. — John
Re: [julia-users] Re: Style Guideline
On Wed, Jan 1, 2014 at 12:35 AM, John Myles White johnmyleswh...@gmail.comwrote: (4) Using both tabs and spaces is a huge problem in a shared codebase. This is probably the only rule in my entire list that I’m actually going to enforce in the code I maintain. IIRC, Python completely forbids mixing these kinds of space characters at the language level. +1 IMHO tabs should totally be avoided. We can configure our editors/IDE to behave tabs like spaces. I know vim does that [set expandtab], and we can use tab key for all general purpose and it expands to spaces. (7) + (8) These rules are part of the official Google style guides for R, which is the language with the most similarity to Julia that’s being used at companies with public facing style guidelines. I think they’re quite sensible rules, which is why I decided to borrow them from published standards. (18) + (19): This is clearly an area of big disagreement in our community. I might pull them out into a suggestions section since I’d really prefer that code submitted to things like DataFrames.jl follow this rule, but don’t want to include a rule that’s going to be a big schism in the community. (22) + (23) + (24): I may take these out as well. I definitely agree that there’s a big difference between performance guidelines and style guidelines, although that line is blurry when you’re trying to keep a codebase written in a consistent style. (31): Comments aren’t PDF’s or HTML or any other language designed for transmitting carefully formatted documents. You don’t get to use images, properly formatted tables, etc. I find diagrams are an essential part of good documentation. I think conflating documents with code leads to documents that are less readable and lots of lines in code that’s not actually worth reading. (35): I might take this one out as well. It’s somewhere on the boundary between a performance tip and a style habit worth developing. — John On Dec 31, 2013, at 11:12 AM, Daniel Carrera dcarr...@gmail.com wrote: Personally, I do not think that a more thorough style guide is necessarily better. That said, I will give you my comments: (4): I like tabs and I use them. (7) + (8): I disagree. Although I generally use comma+space as you say, at times I deviate from that when I feel that doing so will improve the clarity and readability of my code. (18)+(19): I disagree. Although I could favour rules like this in a particular project, in many cases I think that adding type annotations just creates syntactic noise and can create a needless limitation. (22)+(23)+(24): I do not think that performance tips belong in a style guide. You could spend a lot of time writing performance tips and I don't see an obvious reason why the three tips you chose are more important than other performance tips. (31): I partially disagree. I like writing documentation (e.g. tutorial or explaining an algorithm) at the top of the file. I like having the documentation in the same file as the code that it refers to. I do not know what you mean when you say that English documents are more readable when not constrained by the rule of code comments. What rules are those? Also, I rarely want to have a diagram in my documentation because that involves starting a WYSIWYG program like LibreOffice or something like that. I haven't really felt a lot of need for diagrams. (35): This doesn't sound like a style thing either. Advice on the correct way to use a module, or how to maintain precision or avoid round-off errors, do not belong in a style guide. This sort of thing belongs in either the documentation for the module, or on some tutorial about numerical computation. Cheers, Daniel. On Tuesday, 31 December 2013 10:01:23 UTC-5, John Myles White wrote: One of the things that I really like about working with the Facebook codebase is that all of the code was written to comply with a very thorough internal style guideline. This prevents a lot of useless disagreement about code stylistics and discourages the creation of unreadable code before anything reaches the review stage. In an attempt to emulate that level of thoroughness, I decided to extend the main Julia manual’s style guide by writing my own personal style guideline, which can be found at https://github.com/johnmyleswhite/Style.jl I’d be really interested to know what others think of these rules and what they think is missing. Right now, my guidelines leave a lot of wiggle room. — John
Re: [julia-users] Re: Style Guideline
On Tuesday, December 31, 2013 1:45:17 PM UTC-5, John Myles White wrote: Explicit typing isn’t the problem, no? From my perspective, the problem is incorrect typing, not typing per se. My proposal is that one should use explicit Any’s, which doesn’t seem to suffer from the issues you’re raising. As far as I can see, our disagreement would just be between using implicit Any and explicit Any. In the end, I’m not that committed to explicit Any, but I can’t see what harm it does. Sure, an explicit Any type is equivalent to omitting the type, at which point I agree that it is just a matter of style and not semantics. Now I understand what you meant, although I'm not sure I see the attraction of explicit ::Any.
[julia-users] Style Guideline
I like it. Only things that stood out to me were naming functions like variables (prefer functionName()) and the explicit typing (which I could maybe get behind, but I'm not convinced). I too caught the style guide bug when working at Google and I think they really make life nicer. Unfortunately I was using C++ which has 2 space indent so now my Julia code is mixed 2 and 4 space... Woops!
Re: [julia-users] Re: Style Guideline
On Tue, Dec 31, 2013 at 3:39 PM, Daniel Carrera dcarr...@gmail.com wrote: snip I don't think that argument holds water. At all. Google rules are not R rules, and R is not Julia. Companies and projects often have very specific style guides, while entire languages rarely do. I think that style guidelines and coding standards are more common in companies than language communities because they can enforce them. That said, I think that PEP8 in the Python community is a great resource and the fact that the community has a loose consensus to follow them makes working in Python and contributing to Python projects easier. The standardization also means that there's lots of tooling available that helps keep the style consistent. If we can agree that in general having a more prescriptive style guide is a good idea (which I'm guessing will need some more discussion), perhaps discussion of individual rules would be better raised as issues and pull requests in the repo? Hopefully once some consensus is reached the guidelines can be incorporated into the existing Manual and eventually merged in to the docs at http://docs.julialang.org/en/latest/manual/style-guide/ -s
Re: [julia-users] Re: Style Guideline
I do generally like the idea of a style guide, and I make an effort to follow the existing style guide in the manual. Maybe we should see which of John's proposals have wide appeal and add those to the existing style guide? http://docs.julialang.org/en/latest/manual/style-guide/ For example, I think that 1-3 are logical (as a single item). I also like 6, 10-17, 21 (removing the ::Any part), 25-26. I have no opinion on 27-30. But the point I want to make is that there is probably a lot of stuff that would probably get a lot of consensus. Maybe it would be productive to identify which parts of John's proposal have broad agreement, add those to the manual, and argue about the rest later. Just an idea. I think there is much to like in John's proposal. Cheers, Daniel. On 31 December 2013 20:05, Spencer Russell s...@mit.edu wrote: On Tue, Dec 31, 2013 at 3:39 PM, Daniel Carrera dcarr...@gmail.com wrote: snip I don't think that argument holds water. At all. Google rules are not R rules, and R is not Julia. Companies and projects often have very specific style guides, while entire languages rarely do. I think that style guidelines and coding standards are more common in companies than language communities because they can enforce them. That said, I think that PEP8 in the Python community is a great resource and the fact that the community has a loose consensus to follow them makes working in Python and contributing to Python projects easier. The standardization also means that there's lots of tooling available that helps keep the style consistent. If we can agree that in general having a more prescriptive style guide is a good idea (which I'm guessing will need some more discussion), perhaps discussion of individual rules would be better raised as issues and pull requests in the repo? Hopefully once some consensus is reached the guidelines can be incorporated into the existing Manual and eventually merged in to the docs at http://docs.julialang.org/en/latest/manual/style-guide/ -s -- When an engineer says that something can't be done, it's a code phrase that means it's not fun to do.
