Asked  7 Months ago    Answers:  5   Viewed   25 times

I want a function that returns -1 for negative numbers and +1 for positive numbers. It's easy enough to write my own, but it seems like something that ought to be in a standard library somewhere.

Edit: Specifically, I was looking for a function working on floats.



Surprised no one has posted the type-safe C++ version yet:

template <typename T> int sgn(T val) {
    return (T(0) < val) - (val < T(0));


  • Actually implements signum (-1, 0, or 1). Implementations here using copysign only return -1 or 1, which is not signum. Also, some implementations here are returning a float (or T) rather than an int, which seems wasteful.
  • Works for ints, floats, doubles, unsigned shorts, or any custom types constructible from integer 0 and orderable.
  • Fast! copysign is slow, especially if you need to promote and then narrow again. This is branchless and optimizes excellently
  • Standards-compliant! The bitshift hack is neat, but only works for some bit representations, and doesn't work when you have an unsigned type. It could be provided as a manual specialization when appropriate.
  • Accurate! Simple comparisons with zero can maintain the machine's internal high-precision representation (e.g. 80 bit on x87), and avoid a premature round to zero.


  • It's a template so it might take longer to compile in some circumstances.
  • Apparently some people think use of a new, somewhat esoteric, and very slow standard library function that doesn't even really implement signum is more understandable.
  • The < 0 part of the check triggers GCC's -Wtype-limits warning when instantiated for an unsigned type. You can avoid this by using some overloads:

    template <typename T> inline constexpr
    int signum(T x, std::false_type is_signed) {
        return T(0) < x;
    template <typename T> inline constexpr
    int signum(T x, std::true_type is_signed) {
        return (T(0) < x) - (x < T(0));
    template <typename T> inline constexpr
    int signum(T x) {
        return signum(x, std::is_signed<T>());

    (Which is a good example of the first caveat.)

Tuesday, June 1, 2021
answered 7 Months ago

If you use one of the "named curves" then the public key size is fixed and dependent on the "field size" of your underlying curve.

Compressed vs. uncompressed representation

Public key sizes further depend on whether the "uncompressed" representation or the "compressed" representation is used. In the uncompressed form, the public key size is equal to two times the field size (in bytes) + 1, in the compressed form it is field size + 1. So if your curve is defined on secp256r1 (also called NIST P-256 or X9.62 prime256v1), then the field size is 256 bits or 32 bytes. And therefore the public key would be exactly 65 bytes (32*2 +1) long in the uncompressed form and 33 bytes (32 +1) long in the compressed form.

The uncompressed form consists of an 0x04 (in analogy to the DER OCTET STRING tag) plus the concatenation of the big-endian binary representation of the x coordinate plus the binary representation of the y coordinate of the public point.

GF(p) case

If the underlying field is GF(p) where p is a a big prime (in the case of P-256, a 256-bit prime), then x and y can be thought of as elements from [0, p-1]. They are encoded in the usual way as ((log2(p)+1)/8)-byte integers, with the MSBs padded with zero if necessary.

GF(2^m) case

For GF(2^m) x and y can be thought of as polynomials a_0 + a_1x + a_2x^2 + ... + a_{m-1}x^{m-1} with coefficients a_i equal to either 0 or 1. Their binary representation is simply the concatenation of the coefficients.

Further reading

The exact details can be found in SEC1v2. (Especially section 2.3.3 Elliptic-Curve-Point-to-Octet-String Conversion on pages 10 and 11.)

Thursday, July 29, 2021
answered 4 Months ago

I found this blog on the subject intresting:

also has some recommendations for books.

Saturday, September 4, 2021
answered 3 Months ago

There's no ISO standard, but there are ITU standards. You want E.123 and E.164.

In summary, any phone number is represented by +CC MMMMMM... where CC is the country code, and is one to three digits, and MMMMMM... is the area code (where applicable) and subscriber number. The total number of digits may not be more than 15. The + means "your local international dialling prefix".

I'll give a few examples using my own land line number.

So, for example, if you are in Germany, the number +44 2087712924 would be dialled as 00442087712924, and in the US you would dial it as 011442087712924. The 44 means that it is a UK number, and 2087712924 is the local part.

In practice, the long string of MMMMM... is normally broken up into smaller parts to make it easier to read. How you do that is country-specific. The example I give would normally be written +44 20 8771 2924.

As well as the unambiguous E.123 representation above, which you can use from anywhere in the world that allows international dialling, each country also has its own local method of representing numbers, and some have several. The example number will sometimes be written as 020 8771 2924 or (020) 8771 2924. The leading 0 is, strictly speaking, not part of the area code (that's 20) but a signal to the exchange meaning "here comes a number that could go outside the local area". Very occasionally the area code will be ommitted and the number will be written 8771 2924. All these local representations are ambiguous, as they could represent valid numbers in more than one country, or even valid numbers in more than one part of the same country. This means that you should always store a number with its country code, and ideally store it in E.123 notation. In particular you should note that phone numbers ARE NOT NUMBERS. A number like 05 is the same as 5. A phone number 05 is not the same as 5, and storage systems will strip leading zeroes from numbers. Store phone numbers as CHAR or VARCHAR in your database.

Finally, some oddities. The example number will be written by some stupid people as 0208 771 2924. This is diallable, but if you strip off the leading 0208 assuming that it is an area code, then the remainder is not valid as a local number. And some countries with broken phone systems [glares at North America] have utterly bonkers systems where in some places you must dial all 10 digits for a local call, some where you must not, some where you must dial 1NNN NNN NNNN, some where you must not include the leading one, and so on. In all such cases, storing the number as +CC MMMMM... is correct. It is up to someone actually making a call (or their dialling software) to figure out how to translate that into a dialable sequence of digits for their particular location.

Tuesday, September 7, 2021
answered 3 Months ago

As an alternative to the solution by @ragfield, you may declare your function as void and return the result manually. Here is an example based on addTwo standard example. Here is the template:

void addtwo P(( int, int));

:Function:       addtwo
:Pattern:        AddTwo[i_Integer, j_Integer]
:Arguments:      { i, j }
:ArgumentTypes:  { Integer, Integer }
:ReturnType:     Manual

:Evaluate: AddTwo::usage = "AddTwo[x, y] gives the sum of two machine 
    integers x and y."
:Evaluate: AddTwo::badargs = "Arguments are expected to be positive numbers"

and the function:

void addtwo( int i, int j) {

Here are examples of use:

In[16]:= AddTwo[1,2]
Out[16]= 3

In[17]:= AddTwo[-1,2]
During evaluation of In[17]:= AddTwo::badargs: Arguments are expected 
to be positive numbers

Out[17]= $Failed

This is a little more "high level" way to do it, in this way you don't have to deal with packets explicitly.

However, I feel that the full error-checking of the input arguments better be performed on the Mathematica side through appropriate patterns, and the option of error messages saved for some internal errors detected in your C code (I actually go further and return to Mathematica just error codes as integers or strings, and let higher-level mma wrappers deal with them and issue messages). You can place those patterns in your template file, or you can wrap your MathLink Mathematica function into another function that will perform the error-checking. I have a very limited experience with Mathlink though, so my opinion here should not perhaps count much.


Per request in the comment (although I wasn't sure that I understood the request correctly):

extern void addeight( void );
extern void addall(void);

static void putErrorMessageAndReturnFailure(const char *fname, const char *msgtag);

void addeight(void)
    int i,j,k,l,i1,j1,k1,l1;


void addall(){
    int *data, len, i = 0,sum = 0;
    if(!MLGetIntegerList(stdlink, &data, &len)){
        MLReleaseInteger32List(stdlink, data, len);

static void putErrorMessageAndReturnFailure(const char *fname, const char *msgtag){

and the template

void addeight P(( ));

:Function:       addeight
:Pattern:        AddEight[{{i_Integer, j_Integer},{k_Integer,l_Integer}},{{i1_Integer,j1_Integer},{k1_Integer,l1_Integer}}]
:Arguments:      { i, j, k ,l, i1,j1,k1,l1 }
:ArgumentTypes:  { Manual }
:ReturnType:     Manual

:Evaluate: AddEight::usage = "AddEight[{{i_Integer, j_Integer},{k_Integer,l_Integer}}, {{i1_Integer, j1_Integer},{k1_Integer,l1_Integer}}] gives the sum as a list: {{i+i1,j+j1},{k+k1,l+l1}}."

:Evaluate: AddEight::badargs = "Arguments are expected to be positive numbers"

void addall P(( ));

:Function:       addall
:Pattern:        AddAll[fst:{{_Integer, _Integer},{_Integer,_Integer}},sec:{{_Integer, _Integer},{_Integer,_Integer}}]
:Arguments:      { Flatten[{fst,sec}]}
:ArgumentTypes:  { Manual }
:ReturnType:     Manual

:Evaluate: AddAll::usage = "AddAll[{{i_Integer, j_Integer},{k_Integer,l_Integer}},{{i1_Integer, j1_Integer},{k1_Integer,l1_Integer}}] gives the total sum of elemens of the sub-lists."

:Evaluate: AddAll::badargs = "Arguments are expected to be positive numbers"

:Evaluate: AddAll::interr = "Internal error - error getting the data from Mathematica"


In[8]:= AddEight[{{1,2},{3,4}},{{5,6},{7,8}}]
Out[8]= {{6,8},{10,12}}

In[9]:= AddEight[{{-1,2},{3,4}},{{5,6},{7,8}}]
During evaluation of In[9]:= AddEight::badargs: Arguments are expected to be positive numbers

Out[9]= $Failed

In[10]:= AddAll[{{1,2},{3,4}},{{5,6},{7,8}}]
Out[10]= 36

In[11]:= AddAll[{{-1,2},{3,4}},{{5,6},{7,8}}]
During evaluation of In[11]:= AddAll::badargs: Arguments are expected to be positive numbers

Out[11]= $Failed
Monday, October 11, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :