- maybe a stupid question - 8 Updates
- What's the correct fmod()-algorithm - 9 Updates
| alessandro volturno <alessandro.volturno@libero.it>: Apr 06 04:57PM +0200 Hello group, as the title of this message says, this is going to be a silly question, but I don't know how to make it by myself. I'm looking for a way to parse the day of the month in a string data with the format of dd.mm.yyyy via scanf. Where the day of the month is given as an integer number of two digits like the following ones: 01, 02, 03, 04, 05, 06, 07, 08, 09 (that should obviously be interpreted as 1, 2, 3, 4, 5, 6, 7, 8, 9) if I try with the format "%2d" I get an erroneus parsing of 0. thank you for your help, alessandro |
| Manfred <noname@add.invalid>: Apr 06 07:42PM +0200 Hi, This is comp.lang.c++, better send this question to comp.lang.c, with a compiling piece of code of what you are trying to achieve. On 4/6/2021 4:57 PM, alessandro volturno wrote: |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 06 07:59PM +0200 > This is comp.lang.c++, better send this question to comp.lang.c, with a > compiling piece of code of what you are trying to achieve. I don't see any necessity for asking this in comp.lang.c only. scanf and sscanf aren't idiomatically C++-functions, but are still included in the standard. |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 06 09:03PM +0300 06.04.2021 17:57 alessandro volturno kirjutas: > I get an erroneus parsing of 0. > thank you for your help, > alessandro #include <iostream> #include <string> #include <sstream> int main() { // test data std::string s = "06.04.2021"; std::istringstream is(s); // parse int day, mon, year; char dot1, dot2; if ((is >> day >> dot1 >> mon >> dot2 >> year) && dot1=='.' && dot2=='.') { std::cout << "day=" <<day << ", mon=" << mon << ", year=" << year; std::cout << "\n"; } else { std::cerr << "Date parsing failed on: " << s << "\n"; return EXIT_FAILURE; } } HTH |
| scott@slp53.sl.home (Scott Lurndal): Apr 06 06:19PM >> but I don't know how to make it by myself. >> I'm looking for a way to parse the day of the month in a string data >> with the format of dd.mm.yyyy via scanf. #include <time.h> char *cp; struct tm tm; cp = strptime("10.07.1925", "%d.%m.%Y", &tm); if (*cp != '\0') { /* Error, unconsumed input */ } else { day = tm.tm_mday; month = tm.tm_mon; year = tm.tm_year; } |
| Rud1ger Sch1erz <nospam_tigre@yahoo.es>: Apr 06 09:19PM +0200 There are many ways, this is via sscanf, as asked: #include <stdio.h> int main(int argc, char** argv) { const char* dateStr = "24.04.2020"; int n, day, month, year; n = sscanf(dateStr, "%d.%d.%d", &day, &month, &year); printf("%d conversions: %d-%d-%d\n", n, day, month, year); return 0; } -- Tschau Rüdiger |
| alessandro volturno <alessandro.volturno@libero.it>: Apr 06 10:05PM +0200 Il 06/04/2021 16:57, alessandro volturno ha scritto: > I get an erroneus parsing of 0. > thank you for your help, > alessandro Thank you all, yes, this is not a strictly C++ question, but your help gave me new points of view on the available possibilities (especially Scott's). The strange thing is that my code (that this afternoon gave me a zero instead of an eight) now behaves correctly even if I didn't make any change. Two are the possibilities: 1) my view is getting worst - since I cannot distingish between a 0 and an 8 anymore when there is too much light 2) the resolution of my screen is too high, numbers are too small and in the GRX program I'm writing, I cannot distinguish between those symbols. maybe both the factors are involved : ) In fact it is strange, but I was sure that my code was not working. Just to make the picture of the game, I'm playing with an Arduino board and one sensor. I read (at time intervals of 20 minutes) Temperature, Pressure and Humidity of a room and after collecting those data writing them in a Micro SD card, I monthly plot the variation of those parameters in a program I am writing using the GRX graphics library. I chosed to use GRX because I did'n t know it and I wanted to give it a try. Allegro library was probably better, but anyway the road was started on that path and so I continue on that. Thank you and sorry if I made you waste some time. alessandro |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Apr 06 02:29PM -0700 > interpreted as 1, 2, 3, 4, 5, 6, 7, 8, 9) > if I try with the format "%2d" > I get an erroneus parsing of 0. Is there some reason you need to use scanf? Note that scanf has undefined behavior on numeric input if the value can't be represented in the target type. For example, this: scanf("%d", &n); has undefined behavior if the input is "100000000000000000000000000000000000000000000000000" (unless int is surprisingly large in your implementation). -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Manfred <noname@add.invalid>: Apr 06 04:51PM +0200 On 4/6/2021 4:06 PM, Richard Damon wrote: > would be 99.99999.. and trunc would round down. Thus the trunc(/y) > always has a chance that if the division is close enough to an integer > value, to round up and cause that range error. To be more precise, in common implementations the largest loss in precision is with addiction and subtraction. Trunc() by itself is trivially exact, since the number of significant digits is well within the exponent range. Multiplication, division and trunc() do have full precision, meaning that the result has the same number of significant digits as the operands. This is not true for addition and, specifically for this case, subtraction; the problem in x/y - trunc(x/y) is the "-", not the trunc per se. In extreme simplification: if a and b have N decimal significant digits, and (a-b) is one order of magnitude (1/10th) smaller than a and b, then (a-b) has N-1 decimal significant digits. If the difference is two orders of magnitude smaller, the result has N-2 significant digits and so on. The key feature of the "shift and subtract" algorithm is that it takes care that the subtractions performed involve quantities that yield exact results in the target representation. |
| Richard Damon <Richard@Damon-Family.org>: Apr 06 10:59AM -0400 On 4/6/21 10:42 AM, Bonita Montero wrote: > That's wrong. The results become more inaccurate as higher as the > exponent-differences are, but the modulo-results are always in the > correct range. Nope, once you get an error in the value of trunc due to round offs, then you get an number out of range. This can occur even for cases with numbers with very little exponent difference. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 06 05:51PM +0200 > Nope, once you get an error in the value of trunc due to round offs, > ... Wrong, the results are just inaccurate, but always in the correct range, i.e. they're never equal or over the expected mangitude of a modulo-ope- ration or below. > ... then you get an number out of range. Not from fmod(). |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 06 05:53PM +0200 > The key feature of the "shift and subtract" algorithm is that it takes > care that the subtractions performed involve quantities that yield exact > results in the target representation. Not always exact, but the results always fit in the expected range. |
| Richard Damon <Richard@Damon-Family.org>: Apr 06 12:07PM -0400 On 4/6/21 11:51 AM, Bonita Montero wrote: > ration or below. >> ... then you get an number out of range. > Not from fmod(). Except as you pointed out they could be negative, and if the division of x/y isn't accurate to the 1s place the results can easily be larger than y as the round off in the division becomes an error in the answer scaled by y. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 06 06:10PM +0200 > x/y isn't accurate to the 1s place the results can easily be larger than > y as the round off in the division becomes an error in the answer scaled > by y. That's not how fmod is specified and actually implemented. |
| Manfred <noname@add.invalid>: Apr 06 06:48PM +0200 On 4/6/2021 5:53 PM, Bonita Montero wrote: >> care that the subtractions performed involve quantities that yield >> exact results in the target representation. > Not always exact, but the results always fit in the expected range. I'd have to check the details, but I'm pretty confident the result is exact with respect to the operands /after/ conversion in the target representation. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 06 06:49PM +0200 > I'd have to check the details, but I'm pretty confident the result is > exact with respect to the operands /after/ conversion in the target > representation. The algorithm in the code I gave couldn't give an out of range result. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 06 01:47PM -0700 On 4/6/2021 3:37 AM, Bonita Montero wrote: >> pick one. > No one needs unlimtited floating-point accuracy. > Bignum-libaries are only suitable for cryptographic purposes, And deep fractal zooms! |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment