Problem statement: You are given Q queries. Each query consists of a single number N. You can perform any of the 2 operations on in each move:
1: If we take 2 integers a and b where N=aXb(a!=1,b!=1) then we can change N=max(a,b).
2: Decrease the value of N by 1. Determine the minimum number of moves required to reduce the value of N to 0
The first line contains the integer Q.
The next Q lines each contain an integer,N .
Output Q lines. Each line containing the minimum number of moves required to reduce the value of N to 0.
For test case 1, We only have one option that gives the minimum number of moves. Follow 3->2 -> 1->0 .
Hence, 3 moves.
For the case 2, we can either go 4->3 ->2 ->1 ->0 or4 -> 2-> 1->0 . The 2nd option is more optimal. Hence, 3 moves.
if a number is N then
I do looping until sqrt(N) to find if it is a prime or not.
if it is a prime number then N=N-1
if it not a prime number,one of the largest factor(say a) is <=sqrt(N) then other will be b=N/a now b>a then put N=b;
increment count(pass by value).
then next iteration for N ,until it is greater than 1.
algorithms works fine with small value but predicts less optimal solution for large values.why?
Forget about matrix calculations. You need to go and study operator overloading and get that working on a basic class first. Once you understand how to do it correctly so you get no errors, then you can move on to the matrix functions.
I don't know; you have to do your own testing. But I find one of the easiest way to debug issues is to create a small test program that just focused on the area that appears not to work. So a small program with a very basic class, that just tests the operator+ overload, would be much easier to understand.
I should have know better since the LCD did not react to power-up - reset and show 5/7 characters - but the power LED was on on the i2c module itself !
Learned few Linux tools on how to troubleshoot i2c, so no big loss.
Now I can proceed with implementing ioctl.
I would like to discuss implementation of Linux ioctl function.
There are few reasons I am posting my question here and not on Linux forum. However, if you feel it is inappropriate you have two options - ignore my request ( preferred to sermon ) or flag it to be removed.
I am basically aware WHAT ioctl does, and have been thru few documents ( Linux Device drivers, CodeProject driver tutorials etc.)
I am trying to implement ioctl "driver" to output (Raspberry Pi) to I2C LCD.
The problems I cannot get straight is how to configure I2C speed (using C++, not Linux commands ) and implement ACK read from slave I2C device.
I understand I2C protocol, but all of the sample codes I have read so far are "limited" to open ioctl file and "write " to I2C slave address.
I like to see or make my own code to implement I2C "start /stop " and read ACK/ NACK from slave.
Any to the point help will as always be appreciated.
So implementations are not time critical. They can use a predefined (max.) clock and have not to care about being slowed down by other tasks on the system.
I have implemented I2C in assembler on micro controllers. Implementing it in C is not a problem but be aware that it might be a frustrating tasks because it can't be simply debugged. I highly recommend to use a logic analyser or at least a storage oscilloscope to check the signals on the bus.
all of the sample codes I have read so far are "limited" to open ioctl file and "write " to I2C slave address.
With device drivers use i2c_transfer(). Have a look at the source of any Linux driver for a I2C device like rtc-pcf8563.c [^].
When using ioctl() on the I2C device just use read():
int fd = open("/dev/i2c-1", O_RDWR);
// Use I2C_SLAVE_FORCE if the device is in use (e.g. when a driver is installed)
ioctl(fd, I2C_SLAVE, addr);
read(fd, buffer, length);
Or use ioctl(I2C_RDWR) or ioctl(I2C_SMBUS) for reading which both does not require the I2C_SLAVE[_FORCE]. In any case check first if the used ioctl() call is supported.
Thanks for replies.
I am currently "on the road" and will reply when I get home.
I did try "just GPIO" , it worked to the point, but it got too convoluted.
Hence I am after using ioctl.
I'll take a look at the bcm2835.h, hopefully I can use it for bcm2837 chip used in RPi 3B.
I think my main concern is still to be able to "see" the code following / running the I2C spec - mainly changing hardware pins directions and reading START /STOP and ACK/NACK back. Of course I am verifying the actual LCD and sometime even using scope.
I converted VS2008 solution (sln) to VS2017. Visual Studio is up-to-date - version 15.6.4.
My solution contains tens of C++ projects - executables, dll's and lib's. Now I have a weird issue - dll's cannot be debugged in Debug configuration.
In Release configuration it works - breakpoints can be used.
But in Debug configuration all the breakpoints are disabled and there is a hint - "The breakpoint will not currently be hit. No symbols have been loaded for this document."
When I try to load symbols (pdb) manually I'm getting a message "A matching symbol file was not found in this folder."
In DLL project settings (vcxproj file) GenerateDebugInformation is true.
I'm a bit confused why generated pdb file cannot be used by Visual Studio.