I mean to set the default legend font size (and other properties as well) in my Octave script.
Both set (activated separately)
legend_fontsize = 14;
set(0, "defaultlegendlocation", "northoutside");
set(0, "defaultlegendfontsize", legend_fontsize);
produce error: invalid default property specification.
What is the correct syntax?
In Matlab, this suggests it should not throw any error, and it should possibly work.
In theory you are right that this should also work in octave, since according to the manual, octave supports the same syntax, for all kinds of graphical object 'types'.
However, legend is a special case, because it is not implemented as its own graphical object 'type' in octave; instead, as stated in the documentation:
A legend is implemented as an additional axes object with the 'tag'
property set to "legend". Properties of the legend object may be
manipulated directly by using 'set'.
Therefore, this means that the defaultlegendfontsize strategy won't work.
It also means that, since in principle a 'legend' object is an 'axes' object in disguise, set( 0, 'defaultaxesfontsize', 30 ) will work ... but obviously with unintended consequences affecting all axes objects.
You could point that out in the octave bug tracker if you'd like.
In the meantime, you could always do something like the following in your .octaverc as a workaround:
function h = legend( varargin )
% Wrapper to builtin legend function, also setting font to default size of 30
h = builtin( 'legend', varargin{:} )
set( h, 'fontsize', 30 )
endfunction
This effectively shadows the builtin 'legend' command with a custom one, that applies 'default' values as an extra step before returning the handle.
PS: Having said this, one needs to be careful with setting such defaults, in the case of code dissemination and re-use which assumes such defaults are preset in all environments.
This is a common point of caution in R users against creating elaborate .Rprofile files, for instance.
PS 2: Alternatively, a nice approach when you have lots of defaults to apply would be to create a function applydefaults( handle ) which applies all your preferences in one go, and call it at the end of whatever object you want to apply these to. This is what I used to do in my thesis. It may sound like slightly more effort, but you end up thanking yourself 1 month down the line when it's 100% clear what is happening and where the formatting changes came from!
Related
I'm a bit confused over the difference between docstrings and comments in python.
In my class my teacher introduced something known as a 'design recipe', a set of steps that will supposedly help us students plot and organize our coding better in Python. From what I understand, the below is an example of the steps we follow - this so call design recipe (the stuff in the quotations):
def term_work_mark(a0_mark, a1_mark, a2_mark, ex_mark, midterm_mark):
''' (float, float, float, float, float) -> float
Takes your marks on a0_mark, a1_mark, a2_mark, ex_mark and midterm_mark,
calculates their respective weight contributions and sums these
contributions to deliver your overall term mark out of a maximum of 55 (This
is because the exam mark is not taken account of in this function)
>>>term_work_mark(5, 5, 5, 5, 5)
11.8
>>>term_work_mark(0, 0, 0, 0, 0)
0.0
'''
a0_component = contribution(a0_mark, a0_max_mark, a0_weight)
a1_component = contribution(a1_mark, a1_max_mark, a1_weight)
a2_component = contribution(a2_mark, a2_max_mark, a2_weight)
ex_component = contribution(ex_mark, exercises_max_mark,exercises_weight)
mid_component = contribution(midterm_mark, midterm_max_mark, midterm_weight)
return (a0_component + a1_component + a2_component + ex_component +
mid_component)
As far as I understand this is basically a docstring, and in our version of a docstring it must include three things: a description, examples of what your function should do if you enter it in the python shell, and a 'type contract', a section that shows you what types you enter and what types the function will return.
Now this is all good and done, but our assignments require us to also have comments which explain the nature of our functions, using the token '#' symbol.
So, my question is, haven't I already explained what my function will do in the description section of the docstring? What's the point of adding comments if I'll essentially be telling the reader the exact same thing?
It appears your teacher is a fan of How to Design Programs ;)
I'd tackle this as writing for two different audiences who won't always overlap.
First there are the docstrings; these are for people who are going to be using your code without needing or wanting to know how it works. Docstrings can be turned into actual documentation. Consider the official Python documentation - What's available in each library and how to use it, no implementation details (Unless they directly relate to use)
Secondly there are in-code comments; these are to explain what is going on to people (generally you!) who want to extend the code. These will not normally be turned into documentation as they are really about the code itself rather than usage. Now there are about as many opinions on what makes for good comments (or lack thereof) as there are programmers. My personal rules of thumb for adding comments are to explain:
Parts of the code that are necessarily complex. (Optimisation comes to mind)
Workarounds for code you don't have control over, that may otherwise appear illogical
I'll admit to TODOs as well, though I try to keep that to a minimum
Where I've made a choice of a simpler algorithm where a better performing (but more complex) option can go if performance in that section later becomes critical
Since you're coding in an academic setting, and it sounds like your lecturer is going for verbose, I'd say just roll with it. Use code comments to explain how you are doing what you say you are doing in the design recipe.
I believe that it's worth to mention what PEP8 says, I mean, the pure concept.
Docstrings
Conventions for writing good documentation strings (a.k.a. "docstrings") are immortalized in PEP 257.
Write docstrings for all public modules, functions, classes, and methods. Docstrings are not necessary for non-public methods, but you should have a comment that describes what the method does. This comment should appear after the def line.
PEP 257 describes good docstring conventions. Note that most importantly, the """ that ends a multiline docstring should be on a line by itself, e.g.:
"""Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""
For one liner docstrings, please keep the closing """ on the same line.
Comments
Block comments
Generally apply to some (or all) code that follows them, and are indented to the same level as that code. Each line of a block comment starts with a # and a single space (unless it is indented text inside the comment).
Paragraphs inside a block comment are separated by a line containing a single #.
Inline Comments
Use inline comments sparingly.
An inline comment is a comment on the same line as a statement. Inline comments should be separated by at least two spaces from the statement. They should start with a # and a single space.
Inline comments are unnecessary and in fact distracting if they state the obvious.
Don't do this:
x = x + 1 # Increment x
But sometimes, this is useful:
x = x + 1 # Compensate for border
Reference
https://www.python.org/dev/peps/pep-0008/#documentation-strings
https://www.python.org/dev/peps/pep-0008/#inline-comments
https://www.python.org/dev/peps/pep-0008/#block-comments
https://www.python.org/dev/peps/pep-0257/
First of all, for formatting your posts you can use the help options above the text area you type your post.
And about comments and doc strings, the doc string is there to explain the overall use and basic information of the methods. On the other hand comments are meant to give specific information on blocks or lines, #TODO is used to remind you what you want to do in future, definition of variables and so on. By the way, in IDLE the doc string is shown as a tool tip when you hover over the method's name.
Quoting from this page http://www.pythonforbeginners.com/basics/python-docstrings/
Python documentation strings (or docstrings) provide a convenient way
of associating documentation with Python modules, functions, classes,
and methods.
An object's docsting is defined by including a string constant as the
first statement in the object's definition.
It's specified in source code that is used, like a comment, to
document a specific segment of code.
Unlike conventional source code comments the docstring should describe
what the function does, not how.
All functions should have a docstring
This allows the program to inspect these comments at run time, for
instance as an interactive help system, or as metadata.
Docstrings can be accessed by the __doc__ attribute on objects.
Docstrings can be accessed through a program (__doc__) where as inline comments cannot be accessed.
Interactive help systems like in bpython and IPython can use docstrings to display the docsting during the development. So that you dont have to visit the program everytime.
I am using Octave version 4.2.2, but I think the question applies to previous versions as well.
I want to know if the following behavior is well-known and caused by my ignorance or if it is a bug that should be addressed, and also if there is a workaround. Note that I am focusing on parallelization in situations where vectorization is not possible, and where copy by values are not an option.
Basically, my problem is that functions such as pararrayfun or parcellfun seem to violate the principle that the properties of handles are passed by reference.
As an example, suppose we define
classdef data_class < handle
properties
data
end
end
and that we want to take each element from the .data property of one object input_arr from this class, apply some stochastic function fancy_func to them, and copy the result to the corresponding index of the .data property of another object arr of this class. The .data property is just a matrix of size 12*1, and we want to have 4 processes that each process 3 elements.
elem_per_process=3;
num_processes=4;
start_indexes={1,4,7,10};
function []=fill_arr(start_idx,num_elems,in_arr_handle,arr_to_fill_handle)
for i=1:num_elems
arr_to_fill_handle.data(start_idx+i-1,:)=fancy_func(in_arr_handle.data(start_idx+i-1,:));
end
end
filler=#(start_idx)fill_arr(start_idx,elem_per_process,input_arr,arr);
cellfun(filler,start_indexes);%works fine
parcellfun(num_processes,filler,start_indexes);% PROBLEM! Nothing is copied
So, this is actually worse that what I thought:
parcellfun copies object handle properties by value
It breaks code that works with cellfun !
A quick look at
<octave_dir>/packages/parallel-3.1.1/parcellfun.m
seems to indicate that the parallelization relies on processes instead of threads (also note pararrayfun uses parcellfun at its core), so this is expected. What bothers me is that it does so without a single warning, while going against the fundamental properties that many Octave users expect to hold.
So, to summarize:
Is this as a (minor) bug?
Is there any way to parallelize using threads instead of processes (for situations where vectorization is not possible, and where copy by value is unacceptable)?
I seek to override a default setting in Octave concerning plots. For instance, I always set box off; when plotting, so I would like to set the box off by default. Perhaps factoryaxesbox is the involved setting (are those factory settings documented anywhere?).
When I see a setting returned by get(0, "factory"), how can I assign a new default to override this?
I have been through this section of the Octave manual, section 15.3.5: Managing Default Properties, but it says little and I find it rather confusing. Object type, root object, child object, … Huh?
Figured it out after some amount of trial and error.
The name of available properties for plots are those returned by get(0, "factory"), without the factory prefix. In order to override any of these, you must prefix the property name with default, in the format set(0, "defaultNameOfProperty", "newsetting").
To set box off by default for all plots:
set(0, "defaultaxesbox", "off")
Before doing this, if you check for the existence of this property defaultaxesbox, using get(0, "default"), you will find nothing, making you wonder if you can set a setting which does not seem to exist. After the assignment has been made with set(), it will show up in get(0, "default").
If the first argument of set() was gca() or some other number, then replace zero with that in the above get().
On the one hand we have:
>> source object
object: make function! [[
"Defines a unique object."
blk [block!] "Object words and values."
][
make object! append blk none
]]
For context we see:
>> source context
context: make function! [[
"Defines a unique object."
blk [block!] "Object words and values."
][
make object! blk
]]
So, for object the object is constructed from a block to which none has been appended. This doesn't change the length, or, to my knowledge, add anything. With context, on the other hand, the object is constructed with the passed-in block, as is.
Why the difference and why, for example, couldn't context just be an alias for object.
Backwards compatibility. We had a context function already in Rebol that worked a particular way (not initializing variables), but we needed a function that initialized variables to none, as a convenience function when creating objects as data structures rather than as code containers.
It made sense to call it object since that is the type name, and since "context" is actually kind of a bad name for objects in a language with context-sensitive semantics (for a more appropriate meaning of the word "context"). It really leads to some confusing conversations. Since R3 has modules now, most of the previous uses of the context function are covered better by modules. Keeping context at all is mostly for backwards compatibility.
The current object function is pretty much a placeholder for a better type construction wrapper that we haven't thought up yet. We need something like it, but there may be subtle changes in its behavior needed that we'll discover with more use. For one thing, the fact that it modifies its spec block makes it not very safe for recursion or concurrency. It will likely end up as a native if that improves it, or maybe as a construct option if that turns out to be a better approach.
One thing that did turn out to be a win is the practice of using the type name without the exclamation point as the name of a type construction function. We changed map to be that as well, and we may end up adding similar constructors for other types, though most that need them have them already.
I'm a big fan of abbrev-mode and I'd like something a bit similar: you start typing and as soon as you enter some punctation (or just a space would be enough) it invokes a function (if I type space after a special abbreviation, of course, just like abbrev-mode does).
I definitely do NOT want to execute some function every single time I hit space...
So instead of expanding the abbreviation using abbrev-mode, it would run a function of my choice.
Of course it needs to be compatible with abbrev-mode, which I use all the time.
How can I get this behavior?
One approach could be to use pre-abbrev-expand-hook. I don't use abbrev mode myself, but it rather sounds as if you could re-use the abbrev mode machinery this way, and simply define some 'abbreviations' which expand to themselves (or to nothing?), and then you catch them in that hook and take whatever action you wish to.
The expand library is apparently related, and that provides expand-expand-hook, which may be another alternative?
edit: Whoops; pre-abbrev-expand-hook is obsolete since 23.1
abbrev-expand-functions is the correct variable to use:
Wrapper hook around `expand-abbrev'.
The functions on this special hook are called with one argument:
a function that performs the abbrev expansion. It should return
the abbrev symbol if expansion took place.
See M-x find-function RET expand-abbrev RET for the code, and you'll also want to read C-h f with-wrapper-hook RET to understand how this hook is used.
EDIT:
Your revised question adds some key details that my answer didn't address. phils has provided one way to approach this issue. Another would be to use yasnippet . You can include arbitrary lisp code in your snippet templates, so you could do something like this:
# -*- mode: snippet -*-
# name: foobars
# key: fbf
# binding: direct-keybinding
# --
`(foo-bar-for-the-win)`
You'd need to ensure your function didn't return anything, or it would be inserted in the buffer. I don't use abbrev-mode, so I don't know if this would introduce conflicts. yas/snippet takes a bit of experimenting to get it running, but it's pretty handy once you get it set up.
Original answer:
You can bind space to any function you like. You could bind all of the punctuation keys to the same function, or to different functions.
(define-key your-mode-map " " 'your-choice-function)
You probably want to do this within a custom mode map, so you can return to normal behaviour when you switch modes. Globally setting space to anything but self-insert would be unhelpful.
Every abbrev is composed of several elements. Among the main elements are the name (e.g. "fbf"), the expansion (any string you like), and the hook (a function that gets called). In your case it sounds like you want the expansion to be the empty string and simply specify your foo-bar-for-the-win as the hook.