On WinCE, when using printf, what are the qualifiers for various data types - short, unsigned long etc.
For short and ulong, I know the answers are %hd & %lu, I am actually looking for a MSDN site that lists all data types and their qualifiers on CE. Unfortunately I cannot find the site now. I have already looked at this post, but it does not contain the link or answer.
Would this MSDN article : Format Specification Fields: printf and wprintf Functions (for Platform Builder for Microsoft Windows CE 5.0) answer your question ?
Completed with printf Type Field Characters, that is.
Related
I know that by using 0:3 in this code in Pascal will put 3 decimal places to the result
var a,b:real;
begin
a:=23;
b:=7;
writeln(a/b:0:3);
readln;
end.
What I would like to know is if anyone has a source to learn what this : will do with other variables or if adding for example 0:3:4 will make a difference. Basically what : can do to a variable
For the exact definition of write parameters take a look at ISO standards 7185 and 10206, “Standard Pascal” and “Extended Pascal” respectively. These references are useless though if your compiler’s documentation does not make a statement regarding compliance with them. Other compilers have their own non-standard extensions, so the only reliable source of reference is your compiler’s documentation or even its source code if available.
[…] what this : will do with other variables […] Basically what : can do to a variable
As MartynA already noted this language is imprecise: The variables’ values are only read by write/writeLn/writeStr, thus leaving them unmodified.
[…] if adding for example 0:3:4 will make a difference.
To my knowledge a third write parameter is/was only allowed in PXSC, Pascal eXtensions for Scientific Computing. In this case the third parameter would indicate for the rounding mode (nonexistent or 0: closest printable number; greater than zero: round up; less than zero: round down).
On the documentation page for xgboost for python we see a feature_types https://xgboost.readthedocs.io/en/latest/python/python_api.html parameters but have no idea what are the possible values.
The documentation is really bad.
What are the possible values for feature_types?
The documentation seems poor as you say, searching through the XGBoost source code on Github gives some tests that show these options:
int
float
q: quantitative
i: indicator
While it is a bit difficult to figure out what these mean, some other sites list some additional information:
i: "i means this feature is binary indicator feature"
q: "means this feature is a quantitative value, such as age, time, can be missing"
int: "means this feature is integer value (when int is hinted, the decision boundary will be integer)"
Link: another StackOverflow post that mentions the q and i types.
In XGBoosts core.py code you can also find a comment on types:
# use quantitative as default
# {'q': quantitative, 'i': indicator}
Looking at the XGBoost code, from the rest of it, the type parsing goes into the underlying c-based backend code, so that is a bit of a black box still unless you want to go explore it.. :)
What is the maximum length of variable names in the [ALIAS] section of HHP files?
I_AM_WONDERING_ABOUT_THE_MAXIMUM_LENGTH_OF_THIS_STRING_RIGHT_HERE=this-is-some-really-helpful-html-file.html
I have found a CHM/HHP specification right here:
https://www-user.tu-chemnitz.de/~heha/viewchm.php/hs/chmspec.chm/hhp.html
That page only talks about the length of the overall line, though (and not about the length of the variable name). Very specific question, I know. Still, someone may be able to point me somewhere.
As far as I know never asked before and I never heard about limitations. But I think this is because nobody used long variable names in this place so far.
The purpose of the two files e.g. alias.h and map.h is to ease the coordination between developer and help author. The mapping file links an ID to the map number - typically this can be easily created by the developer and passed to the help author. Then the help author creates an alias file linking the IDs to the topic names. That was the idea behind years (decades) ago by Ralph Walden (ex Microsoft).
Please note HTMLHelp is about 20 years old and these context ID strings inside a alias.h file were derived from WinHelp as a predecessor of HTMLHelp.
You'll find some further Information at Creating Context-Sensitive Help for Applications.
In general I'd recommend to use ID's with a fixed format because of the better legibility like shown below:
;-------------------------------------------------------------
; alias.h file example for HTMLHelp (CHM)
; www.help-info.de
;
; All IDH's > 10000 for better format
; last edited: 2006-07-09
;---------------------------------------------------
IDH_90001=index.htm
IDH_10000=Context-sensitive_example\contextID-10000.htm
IDH_10010=Context-sensitive_example\contextID-10010.htm
IDH_20000=Context-sensitive_example\contextID-20000.htm
IDH_20010=Context-sensitive_example\contextID-20010.htm
I'd recommend to use less than 1024 bytes per line.
I am a beginner to Unix programming and C and I have two questions regarding the stat struc and its field st_mode:
When accessing the st_mode field as below, what type of number is returned ( octal, decimal, etc.)?
struct stat file;
stat( someFilePath, &file);
printf("%d", file.st_mode );
I thought the number is in octal but when I ran this code, and I got the value 33188. What is the base?
I found out that the st_mode encodes a 16 bit binary number that represents the file type and file permissions. How do I get the 16-bit number from the above output (especially when it doesn't seem to be in octal). And which parts of the 16-bit digit encode which information?
Thanks for any help.
The actual type behind mode_t and how it encodes information is implementation defined. The only thing that's certain is that it's a bitmask.
To work with st_mode, use the flags and macros defined in the sys/stat.h header. For a list of those defines, consult:
man 2 stat
If you truly need to know what each bit represents, or are simply curious, read the header or use printf to inspect the flags.
What does plus mean in method declarations in Perl6?
Here is an example from spec
submethod BUILD (+$tail, +#legs, *%extraargs) {
$.tail = $tail;
#:legs = #legs;
}
2019 Update See the section Variadic positionals destructuring; +#foo and *#foo in my answer to the SO question "variable number of arguments to function/subroutine".
In 2015 Larry Wall introduced the + parameter prefix, one of four parameter prefixes (*, **, +, |) that signify slurpy (variadic) parameters. He added it to the Rakudo compiler, added some tests, gave a brief informal description of it on the irc channel, and added a section on it to the relevant language design doc.
The example quoted in the original question is taken from an archive of an informal document written and frozen in time over a decade ago. At that time a + parameter prefix signified a named parameter as contrasted with a positional one. Nowadays we use : for that, thus:
submethod BUILD (:$tail, :#legs, *%extraargs) {
$.tail = $tail;
#.legs = #legs;
}
Your "spec" links goes to a historical document, and the syntax has long gone from Perl 6. I'm not sure what it used to do, maybe "at least one argument", in analogy to the + quantifier in regexes.
For an up-to-date specification, please read http://perlcabal.org/syn/S06.html which contains all the information on signatures and subroutines.