Why in various programming documentation for functions do they have square brackets around parameters, but they are ordered such that the later parameters seem to be subsets of the first? Or if the brackets in that language delineate arrays it's as if the second parameter is supposed to be inside of the array of the first, but often the parameters are not even supposed to be arrays, and also they have commas in weird places.
I've seen this style all over the place and tried to find some place where it is written down why they do this. Maybe someone just arbitrarily decided on that and other programmers thought, "oh that looks cool, I'll try that in writing my own documentation.."
Or maybe there is some big book of rules for how to make programming docs? If so I'd like to know about it.
Here is an example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice
if you go to the link in the blue box near the top of the page right bellow the h2? heading "syntax" it says this: arr.slice([begin[, end]]) meaning that the first parameter is begin, and the next parameter is end, for the slice method. When you first see something like this it looks like the brackets and commas are randomly placed.. but they do it all over the place and the same way. There must be some method to the madness!
Brackets around a parameter name indicate that it is an optional parameter. E.g. you can call the slice method without an end parameter. This is just a general rule of language syntax documentation, square brackets indicate optional words/tokens.
Related
I would like to include the equation for a "power-law" curve I am creating using pyplot. I have tried several variations of the following code:
ax.text(0.1,0.9,r'{0:}x$^{1:}$'.format(A,b))
of course the text renderer uses the curly brackets as well as the format statement. I have tried doubling the curly brackets to have
ax.text(0.1,0.9,r'{0:}x$^{{1:}}$'.format(A,b))
and even tripling them
ax.text(0.1,0.9,r'{0:}x$^{{{1:}}}$'.format(A,b))
I have also tried splitting the text into two lines
exponent = '{0:}$'.format(b)
ax.text(0.1,0.9,r'{0:}x$^'.format(A)+exponent)
none of these really make sense to me or to pyplot, but I can't seem to ask the right search question to get this to work. I have found answers that suggested splitting the line and using double curly brackets but nothing that will make this work. Is this possible?
EDIT:
Through further experimentation I have answered the question above which was a simplified version of the equation I wanted to put in the plot, so let me change this question slightly. To do what I wanted above I have found that:
ax.text(0.1,0.9,r'{0:}x$^{{ {1:} }}$'.format(A,b))
works. I don't know why I hadn't tried it earlier, but I have now. The problem is that I actually want a subscript on x as well. Given that the above works I would have thought that:
ax.text(0.1,0.9,r'{0:}x$^{{ {1:} }}_{{\rm map}}$
would work, but I get the following error:
Subscript/superscript sequence is too long. Use braces { } to remove
ambiguity. (at char 0), (line:1, col:1)
I cannot see where to add braces that will remove any ambiguity. Can anyone tell me what I need to do?
This works:
ax.text(0.1, 0.9, r'${0:}x^{{{1:}}}_{{\rm map}}$'.format(A, b))
The issue was that your x was outside of the mathmode ($...$).
With regards to the double curly braces, there is an easy explanation: When using the format function all single curly braces are matched with an argument to the format function (they can also be nested). Two subsequent curly braces are the defined way of getting one curly bracket after applying format. See the documentation for more information on this.
In the same application I have two different instances of wxStaticText. Each displays an angular value expressed in degrees. I've tested both instances for font name and font encoding. They are the same for both. I've tested that both strings passed to SetLabel() are using the same character value, decimal 176. Yet one displays the 'degree' character (small circle, up high) as expected and the other instead displays an odd character I'm not familiar with. How can this be? Is there some other property of wxStaticText I need to test?
I can't explain what you're seeing because obviously two identical controls must behave in the same way, but I can tell you that using decimal 176 is not a good way to encode the degree sign, unless you explicitly use wxConvISO8859_1 to create the corresponding wxString.
It is better to use wxString::FromUTF8("\xc2\xb0") instead or, preferably, make sure that your source files are UTF-8 encoded and just use wxString::FromUTF8("°").
Arghhhh! Found it. I was assuming SetLabel() was wxStaticText::SetLabel(), inherited from the wxWindow base class. It's not. We have a wrapper class of our own around wxStaticText that I was not aware of. It's the wrapper class that is bollixing the string value.
Moral: When debugging unfamiliar code, don't make assumptions, step ALL THE WAY in.
I've implemented auto completion to a combobox like this article shows. Is it possible to make it search for substrings instead of just the beginning of the words?
http://www.codeproject.com/Articles/2371/IAutoComplete-and-custom-IEnumString-implementatio
I haven't found any way to customize how IEnumString/IAutoComplete compares the strings. Is it possible?
The built in search options help a bit but it is complete chaos. To find instring matches you need to set flag AcoWordFilter. But this will prevent from numbers being matched!! However, there is a trick to get the numbers to match: preced with a double-quote as in "3 to find a string containing or starting with "3". Some more chaos? In the AcoWordFilter you also need to prefix other characters not considered part of a "word", eg. you need to prefix parentheses with a " but then you will not find parentheses at the first position!
So the solution is either to create your own implementation of IAutoComplete or offer the user to switch between the modes (a bit awkward).
I dont think that the MS engineers are especially proud of such chaos. How about one more option: AcoSearchAnwhere?
After retrieving the Edit control's IAutoComplete interface, query it for an IAutoComplete2 interface. Calling its SetOptions member you can disable prefix filtering by specifying the ACO_NOPREFIXFILTERING AUTOCOMPLETEOPTIONS.
This is available on Windows Vista and later. If you need a solution that works with pre-Vista versions, you'll have to write your own.
Following conversion
SELECT to_tsvector('english', 'Google.com');
returns this:
'google.com':1
Why does TSearch2 engine didn't return something like this?
'google':2, 'com':1
Or how can i make the engine to return the exploded string as i wrote above?
I just need "Google.com" to be foundable by "google".
Unfortunately, there is no quick and easy solution.
Denis is correct in that the parser is recognizing it as a hostname, which is why it doesn't break it up.
There are 3 other things you can do, off the top of my head.
You can disable the host parsing in the database. See postgres documentation for details. E.g. something like ALTER TEXT SEARCH CONFIGURATION your_parser_config
DROP MAPPING FOR url, url_path
You can write your own custom dictionary.
You can pre-parse your data before it's inserted into the database in some manner (maybe splitting all domains before going into the database).
I had a similar issue to you last year and opted for solution (2), above.
My solution was to write a custom dictionary that splits words up on non-word characters. A custom dictionary is a lot easier & quicker to write than a new parser. You still have to write C tho :)
The dictionary I wrote would return something like 'www.facebook.com':4, 'com':3, 'facebook':2, 'www':1' for the 'www.facebook.com' domain (we had a unique-ish scenario, hence the 4 results instead of 3).
The trouble with a custom dictionary is that you will no longer get stemming (ie: www.books.com will come out as www, books and com). I believe there is some work (which may have been completed) to allow chaining of dictionaries which would solve this problem.
First off in case you're not aware, tsearch2 is deprecated in favor of the built-in functionality:
http://www.postgresql.org/docs/9/static/textsearch.html
As for your actual question, google.com gets recognized as a host by the parser:
http://www.postgresql.org/docs/9.0/static/textsearch-parsers.html
If you don't want this to occur, you'll need to pre-process your text accordingly (or use a custom parser).
I set the culture to Hungarian language, and Chr() seems to be broken.
System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"
Chr(254)
This returns "ţ" when it should be "þ"
However, Asc("ţ") returns 116.
This: Asc(Chr(254)) returns 116.
Why would Asc() and Chr() be different?
I checked and the 'wide' functions do work correctly: ascw(chrw(254)) = 254
Chr(254) interprets the argument in a system dependent way, by looking at the System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage property. See the MSDN article about Chr. You can check whether that value is what you expect. "hu-US" (the hungarian locale as used in the US) might do something strange there.
As a side-note, Asc() has no promise about the used codepage in its current documentation (it was there until 3.0).
Generally I would stick to the unicode variants (ending on -W) if at all possible or use the Encoding class to explicitly specify the conversions.
My best guess is that your Windows tries to represent Chr(254)="ţ" as a combined letter, where the first letter is Chr(116)="t" and the second ("¸" or something like that) cannot be returned because Chr() only returns one letter.
Unicode text should not be handled character-by-character.
It sounds like you need to set the code page for the current thread -- the current culture shouldn't have any effect on Asc and Chr.
Both the Chr docs and the Asc docs have this line:
The returned character depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class. TextInfo.ANSICodePage can be obtained by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
I have seen several problems in VBA on the Mac where characters over 127 and some control characters are not treated properly.
This includes paragraph marks (especially in text copied from the internet or scanned), "¥", and "Ω".
They cannot always be searched for, cannot be used in file names - though they could in the past, and when tested, come up as another ascii number. I have had to write algorithms to change these when files open, as they often look like they are the right character, but then crash some of my macros when they act strangely. The character will look and act right when I save the file, but may be changed when it is reopened.
I will eventually try to switch to unicode, but I am not sure if that will help this issue.
This may not be the issue that you are observing, but I would not rule out isolated problems with certain characters like this. I have sent notes to MS about this in the past but have received no joy.
If you cannot find another solution and the character looks correct when you type it in, then I recommend using a macro snippet like the one below, which I run when updating tables. You of course have to setup theRange as the area you are looking at. A whole file can take a while.
For aChar = 1 To theRange.Characters.count
theRange.Characters(aChar).Select
If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
Next aChar