I want to define global variables in an xcos/scicos signal flow diagram. I tried the block Simulation>set context:
But then it does not accept it as a known variable anywhere:
P.S. I tried the block diagram on a different computer and it now works with semicolons. Apparently this was a glitch or a bug!
OK, this is a bit strange but for some reason that semicolon at the end was the issue! So if you just omit the ; and put variables line by line it all works out:
a = 2
b = 3
...
More elaborate tutorial on how/why using the set context here.
Related
I am new to sage and have got a code (link to code) which should run.
I am still getting an error message in the decoding part. The error trace looks like this:
in decode(y)
--> sigma[i+1+1] = sigma[i+1]*(z)\
-(delta[i+1]/delta[mu+1])*z^(i-mu)*sigma[mu+1]*(z);
in sage.structure.element.Element.__mul__
if BOTH_ARE_ELEMNT(cl):
--> return coercion_model.bin_op(left, right, mul)
in sage.structure.coerce.CoercionModel_cache_maps.bin_op
--> action = self.get_action(xp,yp,op,x,y)
...... some more traces (don't actually know if they are important)
TypeError: positive characteristics not allowed in symbolic computations
Does anybody know if there is something wrong in this code snipped? Due to previous errors, I changed the following to get to where I am at the moment:
.coeffs() changed to .coefficients(sparse=False) due to a warning message.
in the code line sigma[i+1+1] = sigma[i+1](z)\
-(delta[i+1]/delta[mu+1])*z^(i-mu)*sigma[mu+1](z); where the error occurs, i needed to insert * eg. sigma[i+1]*(z)
I would be grateful for any guess what could be wrong!
Your issue is that you are multiplying things not of characteristic zero (like elements related to Phi.<x> = GF(2^m)) with elements of symbolic computation like z which you have explicitly defined as a symbolic variable
Phi.<x> = GF(2^m)
PR = PolynomialRing(Phi,'z')
z = var('z')
Basically, the z you get from PR is not the same one as from var('z'). I recommend naming it something else. You should be able to access this with PR.gen() or maybe PR(z).
I'd be able to be more detailed, but I encourage you next time to paste a fully (non-)working example; trying to slog through a big worksheet is not the easiest thing to track all this down. Finally, good luck, hope Sage ends up being useful for you!
I have a question, I have been reviewing some code and in one script, the authors use:
if(0){
#do something
}
Any help in what if(0) means?
The author (most likely) put the block of code in an if statement so that they could easily remove it if necessary without having to comment it out (or remove it). Similar to if(true) or if(false), you just need to change one value and it would skip that code.
Upon reviewing the code, developers should remove these kinds of statements once they've finalized all their source code not to confuse others.
Looks like something that will never be executed, since 0 = FALSE. Most probably this is a manual switch to test some code in parenthesis.
I am new to programming with no formal programming training, so please excuse this newbie question. I can't seem to find a definitive answer on it, and need to be sure.
Here's the scenario: sometimes I need to try different lines of code to see if they work, but still want to keep the original lines in there in case the new lines don't work (or for future reference). I thought by putting // in front of the line I want to "comment out" would mean the line of code would be ignored when compiling the program, but my app crashed and pointed to a line I thought was commented out. I am using Xcode 4.
Is there another symbol I should be using to comment out lines or blocks of code? For example, will /* at the beginning and */ at the end accomplish this?
For "commenting out" big blocks of code, I do conditionals like:
#if I_AM_TESTING_SO_DONT_COMPILE_THIS
...
...
...
...
#endif // I_AM_TESTING_SO_DONT_COMPILE_THIS
And yes, the traditional C-style /* and */ also work to "comment out" blocks of code.
The reason your compile crashed with // is because while a single line gets commented out, you might have had some extra code on a second line.
Such as:
//NSString * someContentFromSomewhere = [[NSString alloc] initWithContentsOfURL:
[NSURL URLWithString: #"http://www.stackoverflow.com"]];
The first line is commented out. The second line is a syntax error.
Also, make sure you do a clean build. It's possible that sometimes old object files are used and even though you commented out a line in the IDE, it may not have build with that updated file.
This question already has answers here:
Multiline Comment Workarounds?
(11 answers)
Closed 9 years ago.
I found this old thread (from over a year ago), which explains how come R doesn't support a multi-line comments (like /* comment */ of PHP, for example).
I am wondering if this has been resolved in the past year, or if there are other alternatives? (For example, in notepad++ with npptor, you can mark a bunch of lines and press ctrl+q to mark them all as comments, are there similar solutions for other IDE's ?)
R Studio (and Eclipse + StatET): Highlight the text and use CTRL+SHIFT+C to comment multiple lines in Windows.
For macOS, use command+SHIFT+C.
You can, if you want, use standalone strings for multi-line comments — I've always thought that prettier than if (FALSE) { } blocks. The string will get evaluated and then discarded, so as long as it's not the last line in a function nothing will happen.
"This function takes a value x, and does things and returns things that
take several lines to explain"
doEverythingOften <- function(x) {
# Non! Comment it out! We'll just do it once for now.
"if (x %in% 1:9) {
doTenEverythings()
}"
doEverythingOnce()
...
return(list(
everythingDone = TRUE,
howOftenDone = 1
))
}
The main limitation is that when you're commenting stuff out, you've got to watch your quotation marks: if you've got one kind inside, you'll have to use the other kind for the comment; and if you've got something like "strings with 'postrophes" inside that block, then there's no way this method is a good idea. But then there's still the if (FALSE) block.
The other limitation, one that both methods have, is that you can only use such blocks in places where an expression would be syntactically valid - no commenting out parts of lists, say.
Regarding what do in which IDE: I'm a Vim user, and I find
NERD Commenter an utterly excellent tool for quickly commenting or uncommenting multiple lines. Very user-friendly, very well-documented.
Lastly, at the R prompt (at least under Linux), there's the lovely Alt-Shift-# to comment the current line. Very nice to put a line 'on hold', if you're working on a one-liner and then realise you need a prep step first.
CTRL+SHIFT+C in Eclipse + StatET and Rstudio.
if(FALSE) {
...
}
precludes multiple lines from being executed. However, these lines still have to be syntactically correct, i.e., can't be comments in the proper sense. Still helpful for some cases though.
No multi-line comments in R as of version 2.12 and unlikely to change. In most environments, you can comment blocks by highlighting and toggle-comment. In emacs, this is 'M-x ;'.
Put the following into your ~/.Rprofile file:
exclude <- function(blah) {
"excluded block"
}
Now, you can exclude blocks like follows:
stuffiwant
exclude({
stuffidontwant
morestuffidontwant
})
Unfortunately, there is still no multi-line commenting in R.
If your text editor supports column-mode, then use it to add a bunch of #s at once. If you use UltraEdit, Alt+c will put you in column mode.
I'm learning the Flex command-line debugger, and I haven't been able to find information on this particular use case.
I'd like to add a breakpoint to a specific line in one of my class files. I can add breakpoints at the start of a function in a class, but I can't figure out how to set it at a specific line (e.g. line 117 in Foo.as)?
When I try to set one for a file on a given line, I get one at a different location:
(fdb) break Foo 111
Breakpoint 1 at 0x######: file Foo.as, line 115
I've verified the line # I'm specifying is valid, so I don't think the FDB is trying to compensate.
Am I doing something wrong? Is this possible in FDB?
Abso-lutely,
check out the help in fdb, it's fairly helpful :). Just type help or type help then a command. help break gives the output below, lots of nice ways to hook in there, the syntax your using is just missing a colon in between the class and the line number specified, just tried with an MXML file and it worked fine.
Set breakpoint at specified line or function.
Examples:
break 87
Sets a breakpoint at line 87 of the current file.
break myapp.mxml:56
Sets a breakpoint at line 56 of myapp.mxml.
break #3:29
Sets a breakpoint at line 29 of file #3.
break doThis
Sets a breakpoint at function doThis() in the current file.
break myapp.mxml:doThat
Sets a breakpoint at function doThat() in file myapp.mxml.
break #3:doOther
Sets a breakpoint at function doOther() in file #3.
break
Sets a breakpoint at the current execution address in the
current stack frame. This is useful for breaking on return
to a stack frame.
To see file names and numbers, do 'info sources' or 'info files'.
To see function names, do 'info functions'.
Abbreviated file names and function names are accepted if unambiguous.
If line number is specified, break at start of code for that line.
If function is specified, break at start of code for that function.
See 'commands' and 'condition' for further breakpoint control.