Comments by Daniel Pfeffer (Top 44 by date)

Any basic tutorial on network protocols will have a similar example. I suggest searching for "Internet Protocol Tutorial" or "UDP protocol tutorial".

I am not an SQL expert, but perhaps the problem is in the database schema. Are you certain that the strings stored in the database are Unicode strings? If they are ASCII strings, it is quite possible that the database won't recognize them - Arabic is not defined in ASCII.

See the following: https://learn.microsoft.com/en-us/sql/t-sql/data-types/data-types-transact-sql?view=sql-server-ver15

The MultiByteToWideChar() API is part of the Windows SDK, and requires including windows.h

There is a good example using C only here: https://en.cppreference.com/w/cpp/string/multibyte/mbstowcs

Please note that the string passed to setlocale() is compiler-dependent; you will have to consult your compiler's documentation to see how to set up a UTF-8 locale.

all variables, the "magical constant" 0x19999999, and the result must all be unsigned 32-bit values. If the results are signed, then they may overflow the signed 32-bit representation.
If an unsigned 32-bit value is unavailable, you could handle this (with extra complexity) by splitting the 64-bit value into four 16-bit values, each stored in a signed 32-bit variable, and using multiple-precision division to extract the digits in a similar manner.

Python and C (or C++) are very different languages. Rather than trying to translate Python code to C or C++, you will probably find it easier to write the program from the beginning. For your code, this should not be very difficult.

BTW, your prime discovery code is extremely inefficient. A few minutes thought should enable you to improve it considerably.

As far as it goes, your code appears to work. Now, answer these questions:

1. Is your multiplication operation commutative? (i.e. should both scalar*vector and vector*scalar be legal?)
2. Can the scalar*vector case be defined inside the class?
3. Is there any good reason for the vector*scalar case to be defined inside the class?

Now review the operator(s) that you have already written, asking these questions for each of them.

I don't see anywhere that you handle the carry correctly. Binary addition is (for each bit):

given carry, a(i), b(i), calculate new carry and c(i) = a(i) + b(i).

c(i) = a(i) ^ b(i) ^ carry
new carry = (a(i) & b(i)) | (a(i) & carry) | (b(i) & carry)

for bits 0 of the operands, set carry = 0.

Note that this is a special case of the generic code for addition in an arbitrary base.

Try spelling Length correctly (not Lenght)

This sounds like a homework problem. If you don't understand it, why not ask your teacher to explain it again to you? That's his/her job...

Yes, the standard library for both languages enables this. Given that this is obviously homework (which the OP made a good attempt at solving), I didn't want to confuse the OP with extraneous details.

Oops! So add a zero to the exponent.

We have an even function, f(x). We wish to develop an approximation, F(x) to f.

When developing an approximation to an even function, you can sometimes get odd components with a very small coefficient. These are due to round off errors in the calculations, and they spoil the evenness of the approximation.

One way to avoid this is to replace 'x' with 'x^2', and calculate a different approximation to f, using the new parameter. This guarantees that the approximation is also even.

I fail to see why dates.reverse() doesn't give you what you want. It reverses the order of the elements of the array, without caring what the values are. An array in ascending order would become an array in descending order.
If your array is not in order, you will have to write a custom sorting function. As you have discovered, dates in US format cannot be sorted as if they were strings.

When simulating many physical systems, you calculate sin(omega*t), where omega is frequency and t is time. These numbers can get quite big - well over 100.0.

As for your other point, we'll have to agree to disagree. :)

x is the argument to your sin() calculation.

No, I didn't run the code; merely looking at the way you implemented the power series is enough. Were any of my comments about the code incorrect? :)

1. pow(x, y) _may_ have an optimization for the case of integral y, but that is not guaranteed. Otherwise, it calculates exp(y*log(x)).
2. Even if the optimization exists, you will have between lg(n) and 2*lg(n) multiplications for _each_ power calculation, with all the associated errors and extra calculation.
3. Horner's rule - f(x) = (...((a[n]*x + a[n-1])*x + a[n-2])*x ...) +a[0] uses n multiplications and n additions to perform the calculation, which is both faster and more accurate.
4. A modern C or C++ compiler provides fma(). Using that reduces the calculation to n fma() operations, with a corresponding increase in accuracy.
5. There is also no need to recalculate the factorial at each stage. It may be calculated "for free" by setting a[2*k+1] = +/-1.0/(2*k*(2*k+1)), a[1] = 1.0.
6. Assuming x is even moderately large (say 100.0), your method will overflow well before you reach acceptable accuracy - you will need at least 150 elements (n = 300), and 300! will overflow well before you reach that.

This will be extremely inaccurate for even small values of x. You should at the very least use Horner's rule in order to evaluate the polynomial. See my solution for other considerations.

When you want to write code that runs on more than one type of Windows (i.e. Win16, Win32, and Win64), they save a lot of effort parsing the messages. I am converting FRACTINT for Windows (a Win16 medium model program) to run as a native Win32/Win64 program, and these macros help a lot.

One possibility is that with more processors, less switching-in and switching-out of threads is necessary. This means that the internal data/instruction cache of each processor is not flushed so often, which in turn means that the functions in general execute more quickly.

Note that this is only a guess. It would be impossible to give you a better answer without a full analysis of the profiling data.

Look at articles about polyominoes.

This sounds like a tiling problem (cover an area with tiles of differing shapes/sizes). A brute-force method would start by writing an algorithm to create all possible 10-tiles, and then writing an algorithm that tries to pack 10 of them in a particular area, but there are probably better methods of doing this.

Assume that you have any number of tiles of each shape. Don't forget rotations and mirrors of tile shapes!

How would you do this by hand?
For example, take the string "abc". How would you extract all of the substrings? Now do the same for "abcd". Do you see the pattern?

Now write it in code.

Not quite. I am saying that if you don't understand how floating-point values are processed in your environment, then numerical software may not function as expected.

This applies to any language implementation - from Fortran to Python. In the case of C#, Microsoft is deliberately ambiguous. It could be that the same thing applies to Python, but I don'the know enough about the internals of the interpreter to tell you.

What you want to write sounds like an extension for MS Office. In order to suggest the next word during ordinary typing, it would have to behave like the "spelling checker", that is it would have to monitor every keystroke entered. Such additions are typically written in VBA, which is a version of Visual Basic for MS Office applications.

There must be tons of stuff about VBA on the 'net. I suggest that you read up on macro extensions for MS Office, and pay close attention to methods for "hooking" the keyboard, that is reading the input text as it is typed.

Reply

Yes, you could. The C or C++ part should be written as a DLL, and you could then call it from a C# program.

A quick Google of "Calling a C++ DLL from C#" should give you plenty of information on how to do this.

Extraction of the integer part by assigning the 'double' to an 'int' is not a good idea. What if the integer part overflows an 'int'?

(e.g. the 'double' value is 2^31, and the 'int' is 32-bit twos complement.)

Other things to check:
1. What is the definition of ARR_SIZE? (by your description, it should be at least 31)
2. result is an array of 10 elements. Are you certain that 'idx' cannot go over 9?
3. Check that the 'query' array has the size the you expect it to have.
...
If all else fails, try stepping through the code with a debugger. See if the results are what you expect at each step.

One way would be to use std::multimap, which allows multiple instances of the same key. You would then have to iterate over all the instances of the key in order to check for the presence of the duplicate.
Another way would be to use a map of std::map<int, std::set<wstring> >, and then insert each duplicate file name in the set. You would then have a two-phase lookup: find files of the appropriate size, and then check the set for the presence of the file name.

Are you using a 16-bit emulator (DOSbox or something similar)? If you are trying to do this in Windows or Linux, this can't be done by user programs.

Your question is unclear; perhaps you could post a short snippet of code to clarify it.

If you are referring to traditional "dumb pointers", these work just as before:

class Base {}
class Derived: public Base {}

void method(Base& base)
{
}

Derived d;
Derived* pd = new Derived();

method(d);
method(*pd);

should work fine.

If dataCustodian does not contain any spaces or slashes, fullName[] will have only one element. This is possible e.g. if you have only a last name, but no first name. I don't see a test for this condition.

See the following URL https://developer.vimeo.com/api/upload/videos and read about resumable HTTP PUT uploads. I assume that VimeoDotNet allows this type of upload...

Sorry; I missed the last line of your comment. In my defence, I did give the OP precisely the help that he asked for, no more and no less.

Look at http://www.codeproject.com/Questions/68575/How-to-print-more-pages-in-C-printdocument. It should give you some ideas...

The easiest way to discover the emulator size is to compile and link the code once for floating-point (assume that you do have FP instructions), and another time for the emulator. IIRC, the emulators used for DOS programs in the '90s (x86 machines, not ARM) were on the order of a few tens of kilobytes.

The only modification that I would make would be to overload the '+=' and '+' operators to perform the matrix addition.

The whole point of an emulator is to provide floating-point capabilities on hardware which does not posses them natively. This was a popular approach up to the '90s, when most CPUs started to have floating-point instructions on-board. There is no reason why it cannot work for you, as well.

IMO, the only reasons not to use an emulator are:
1. You do not have the additional memory required for the emulator
2. The performance of the emulator is insufficient for your needs

Only if either of these is true, should you consider writing your own fixed-point implementation. As you have discovered, writing a numerically stable fixed-point package is a non-trivial task.