I am writing long scripts on one line. I would like to organise my code by breaking code onto multiple lines without having to write a function. How do I do this?
You can separate code over multiple lines as long as you indent each subsequent line. You should use semi colons to separate expressions which are indented.
For example a simple select statement split over multiple lines could look like this;
t:([]a:1 2 3;b:`a`b`c);
res:select
from t
where a<>1,
b in `a`c;
show res
More information can be found here;
http://code.kx.com/q/tutorials/startingq/language/#29-scripts
Related
In org-babel, when tangling code blocks, there is a header argument padline, which, when set to yes, adds an empty line to the end of the block. Can I specify the number of empty lines to be added? Some languages, like Python, have recommended number of empty lines after different objects, how do I make org-babel respect that, when tangling code blocks?
Currently working on a project in which I must take multiple user-inputs. Because my input prompts must outline specific formatting to the user regarding how they should input their values, this makes each input prompt rather lengthy and so I've deemed it appropriate to separate each one with a line break so that it's easy to tell them apart/so that it looks nice. The last prompt is two lines long, so it would be hard to distinguish this one from the rest if they were all jumbled together rather than separated by line breaks.
I've explored the usage of fprintf() and disp(), and have found that fprintf() has some tricky behavior and sometimes will not work without including things like fflushf(), etc. Moreover, I've read that fprintf() is actually purposed for writing data to text files (from the MathWorks page, at least), and using it for another purpose is something I could definitely see my professor deducting points for if there is indeed an easier way (we are graded very harshly on script efficiency).
The disp() command seems to be more in-line with what I'm looking for, however I can't find anything on it being able to support formatting operators like \n. For now, I've resorted to replacing the usage of \n with disp(' '), however this is certainly going to result in a deduction of points.
TL;DR Is there a more efficient way to create line-breaks without using fprintf('text\n')? I'll attach a portion of my script for you to look at:
disp('i) For the following, assume Cart 1 is on the left and Cart 3 is on the right.');
disp('ii) Assume positive velocities move to the right, while negative velocities move to the left.');
prompt = '\nEnter an array of three cart masses (kg) in the form ''[M1 M2 M3]'': ';
m = input(prompt);
prompt = '\nEnter an array of three initial cart velocities (m/s) in the form ''[V1 V2 V3]'': ';
v0 = input(prompt);
disp(' ');
disp('Because the initial position of the three carts is not specified,');
prompt = 'please provide which two carts will collide first in the form ''[CartA CartB]'': ';
col_0 = input(prompt);
You can get disp to display a new line with the newline function. Putting multiple strings in square bracket will concatenate them.
disp(['Line 1' newline 'Line 2'])
You mention using fprintf, but as you found this is meant for writing to files. You can use the sprintf function to display the same formatted strings if desired.
disp(sprintf('Line 1 \nLine 2'))
In addition to Matt's solution, I figured out another way to solve my problem and wanted to post it here for anyone in the future with the same problem.
After some experimentation and some thought, I figured the most efficient way to do this (ideally) would not involve using disp() or fprintf() at all and instead would, in theory, involve actually manipulating the input prompts themselves to appear on multiple lines (rather than adding 'dummy' lines before the last line of each prompt, to make it seem as if it was all part of the prompt itself). I've been aware this whole time that simply a newline character \n will give me a linebreak in the middle of the sentence, and in theory this would work. But because the very last prompt is two lines long, simply typing one line with \n halfway through would make that line of code very long, which is what I was trying to avoid in the first place.
I realize my initial question didn't explicitly mention concatenating two (or more) strings to form an input prompt that appears on multiple lines both in the console and in the script itself, but that's essentially where I was going with this post and I apologize for any lack of clarity regarding this.
Anyways, I fixed this problem without having to use disp() or fprint() by declaring the prompt as a string array, rather than as a single string with the preceding lines of the prompt specified above it using disp() and/or fprintf() as you can see in the code I originally provided in the question. Here's how it looked before:
disp(' ');
disp('Because the initial position of the three carts is not specified,');
prompt = 'please provide which two carts will collide first in the form ''[CartA CartB]'': ';
col_0 = input(prompt);
versus how it looks now:
prompt = ['\nBecause the initial position of the three carts is not specified, please',...
'\nprovide which two carts will collide first in the form ''[CartA CartB]'': '];
col_0 = input(prompt);
In short, you can concatenate portions of the entire prompt by declaring it as a string array and inserting \n where you see fit.
I have some PowerShell cmdlets for which I've created in-code documentation. All works fine except for one thing. If I have a long description for any of the documentation sections I'm splitting it into multiple lines so that it can be easily read from code. However I've noticed that those new line characters are then also represented as new lines in the PowerShell system.
As an example, here's part of the documentation
.PARAMETER MyParam
This parameter has a long documentation that does not fit into single line,
so I'm breaking it down to several lines.
Now once I run Get-Help on a cmdlet that contains this sort of comments I'll get something like.
-MyParam [<SwitchParameter>]
This parameter has a long documentation that does not fit
into single line,
so I'm breaking it down to several lines.
Required? true
Position? named
Default value False
Accept pipeline input? false
Accept wildcard characters? false
Notice that the first line gets wrapped correctly, but then the second line (starting with the word so) also starts on a new line.
I could overcome this problem by putting my whole documentation block in one line but that wouldn't be too good for readability point of view.
Is there a way to treat the whole documentation block as it was part of the same text block but have the comments organized into multiple lines at the same time? Any way that I could tell in the documentation that I don't intend to make a new paragraph and I want to continue previous one?
I don't think this is possible apart from preprocessing help strings with external script.
Use word-wrap in your editor and keep everything on the one line. Keep a hotkey accessible for WW so you can quickly switch from one line to block of text when you need to edit it. Some editors (such as vim) are extremely good in navigating wrapped text (basically the same as it is not wrapped).
I'm writing a program which takes filenames and options on the command line in the usual way, and also can be directed to read arguments from a file. I'm implementing the semi-standard -- to turn off special treatment of subsequent arguments, and # as comment marker.
I also want to implement a marker for 'disregard all arguments from here on', i.e. an end marker. Is there a common/semi-standard way to indicate this? Or, what way would people find least surprising?
I would say implement multiline comments. C style /* */ would only work if you are not using wildcards in paths. XML style <!-- --> or asp <%-- --%> or matlab %{ %} might work. I think XML is the most recognized besides C.
This is also more useful than a simple terminator.
I haven't seen anything like that before. Do you envision the end marker being used during debugging/testing of the options in the file? If so, commenting out the unneeded lines seems like the most reasonable thing to do without adding extra complications.
This is hard to look up: what do the end-of-line commas do in Matlab? In the couple of small tests I've done, they don't seem to make the code behave any different. I'd like to know because they're all over in this code I didn't write (but have to maintain).
Examples of what I mean:
if nargin<1,
% code
end
if isError,
% code
end
try,
% code
while 1,
% even more code
end
catch,
% code
end
According to the documentation for the comma character in MATLAB, one of its functions is to separate statements within a line. If there is only one statement on a line, the comma is not needed. I don't like to see it there, although I know some people write code that way.
As others have pointed out, commas at the end of a line are unnecessary. They are really just for separating statements that are on the same line. mlint and the Editor will even give you a warning if you use one without needing it:
>> mlint comma_test.m
L 1 (C 4): Extra comma is unnecessary.
If you read tightly coded m-files (e.g., many of the built-in MATLAB functions) you will discover a variant of the if ... end construct that is written on one line. Here's an example
if x<0, disp('imaginary'); end
Notice the comma between the x<0 and the disp(...). Apparently the comma tells the MATLAB interpretter that the conditional test has ended. To my knowledge this is only place where a statement (OK, part of a statement) ends with a comma. It's just one of those quirks that true believers come to use without hesitation.
http://web.cecs.pdx.edu/~gerry/MATLAB/programming/basics.html
I think the comma in matlab is like the semicolon in C. It separates commands, so you can put multiple commands in one line separated by commas.
The way your program is written, I believe the commas make no difference.