- C++ comma operator ? - 5 Updates
- olcott is absolutely correct. [ Visual Studio c/c++ project ] - 2 Updates
- Never use strncpy! - 4 Updates
- Mein kleines Meister-Stück - 1 Update
- ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? - 1 Update
- attempt to dereference a singular iterator - 1 Update
| Lynn McGuire <lynnmcguire5@gmail.com>: Sep 30 11:09PM -0500 On 9/30/2022 6:03 PM, Manfred wrote: > overloaded comma operator. > /If/ this is what is actually going on here, then you might need to keep > the sequence of commas in place, or go through some nontrivial rewrite. As time goes on, some of these write statements will be rewritten in conventional c++ code but for now, the Fortran like expression will be good enough. Thanks, Lynn |
| Lynn McGuire <lynnmcguire5@gmail.com>: Sep 30 11:48PM -0500 On 9/29/2022 11:48 PM, Lynn McGuire wrote: > from Fortran to C++ Fable software. > Thanks, > Lynn I just noted that f2c is using the comma operator in translated expressions also, original fortran code: test = abs( sienth(1) - vdy(adia_sienth_ptr+i) ) New C/C++ code: test = (d__1 = sienth[1] - vdyn1.vdy[adia_sienth_ptr + i - 1], abs(d__1)); Interesting. Can abs() under C/C++ not handle the expression inside it ? That does not make sense. Thanks, Lynn |
| scott@slp53.sl.home (Scott Lurndal): Oct 01 04:56PM >namespace fem;" statement to make sure that I get the correct write >function (which is no guarantee at all). Or, if I will have to use >"fem::write". Given C++ supports function signature overloads, I doubt you'll have a problem with this in particular unless you only have a single element iolist. (note that in F77, there were no parentheses in the WRITE statement). |
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 01 01:13PM -0500 On 10/1/2022 11:56 AM, Scott Lurndal wrote: > Given C++ supports function signature overloads, I doubt you'll have > a problem with this in particular unless you only have a single element > iolist. (note that in F77, there were no parentheses in the WRITE statement). I suspect that you are thinking of the Fortran PRINT statement. https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnap/index.html The Fortran WRITE statement has always had parenthesis for the i/o unit and the format. https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnbs/index.html Lynn |
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 01 02:30PM -0500 On 9/30/2022 1:32 PM, Lynn McGuire wrote: > Thanks, > Lynn > Subscripted using hkl(3,i)? I thought this was supposed to be C++ code, not Fortran? They are C++ objects acting like Fortran arrays. Lynn |
| olcott <polcott2@gmail.com>: Oct 01 10:09AM -0500 On 10/1/2022 9:48 AM, Mr Flibble wrote: > inputs, so it is a halt decider and therefore does refute the halting > problem proofs. > /Flibble Unlike the Liar Paradox, the Tarksi Undefinability Theorem sentence and Gödel's 1931 Incompleteness Theorem sentence where the correct answer to, is it true or false is neither, the Halting Problem counter-example is provably non-halting. typedef void (*ptr)(); int H(ptr p, ptr i); // simulating halt decider // P does the opposite of whatever H decides void P(ptr x) { int Halt_Status = H(x, x); if (Halt_Status) // if H(P,P) reports that its input halts HERE: goto HERE; // P loops and never halts return; // else P halts } P specifies non-halting behavior to every simulating halt decider H because P continues to call H to simulate it again until H aborts its simulation of P. *This is easily verified with my fully operational halt decider* Complete halt deciding system (Visual Studio Project) (a) x86utm operating system (b) Complete x86 emulator adapted from libx86emu to compile under Windows (c) Several halt deciders and their sample inputs contained within Halt7.c https://liarparadox.org/2022_09_07.zip -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <none-ya@beez-waxes.com>: Oct 01 01:03PM -0500 On 10/1/2022 12:45 PM, Paul N wrote: >> because P continues to call H to simulate it again until H aborts its >> simulation of P. > How can you yet again completely fail to spot that this won't work, You acknowledged that it does work... On 7/24/2022 6:19 PM, Paul N wrote: > simulate its input until it *correctly* matches a non- > halting behaviour pattern then this SHD is correct when it > aborts its simulation and reports non-halting. typedef void (*ptr)(); // P does the opposite of whatever H decides void P(ptr x) { int Halt_Status = H(x, x); if (Halt_Status) // if H(P,P) reports that its input halts HERE: goto HERE; // P loops and never halts return; // else P halts } // This H(P,P) directly executes P(P) and is non-halting. // and is an input to H // int H(ptr x, ptr y) { x(y); } int main() { P(P); } is not an input to H(P,P) thus is irrelevant to H when it computes the mapping from its inputs... -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Manfred <noname@add.invalid>: Oct 01 01:24AM +0200 On 9/22/2022 1:01 AM, Keith Thompson wrote: > Juha Nieminen <nospam@thanks.invalid> writes: >> Well, *almost* never, at least. [...] > strncpy() is not poorly designed. [...] > It is poorly *named*. Agreed. The name implies that, as strncat is a "safer" > strcat, strncpy is a "safer" strcpy. Both strncat and strncpy let you > specify the size of the target array, avoiding writing past the end of > it, but strncpy treats its target as null-terminated string. (likely typo, sounds like this last bit has been gotten backwards) |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 30 04:43PM -0700 >> specify the size of the target array, avoiding writing past the end of >> it, but strncpy treats its target as null-terminated string. > (likely typo, sounds like this last bit has been gotten backwards) Yes, thank you. strncat() treats its target (but not its source) as a null-terminated string, both before and after copying. strncpy() does not. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 01 06:26AM +0200 Am 28.09.2022 um 23:11 schrieb Scott Lurndal: > real RMW atomics, which were added as part of the LSE (Large System ISA > Extensions). LDADD, LDCLR (and with complement), LDSET (or), LDEOR (xor), > LDSMAX (signed maximum), LDUMAX (unsigned maximum), LDSMIN, LDUMIN. Eh, RMW can be emulated with LL/SC but not vice versa. A CAS emulated by LL/SC isn't slower than a native CAS. But atomic increments, decrements, ands, ors or whatever ebulated with LL/SC is sometimes slower. |
| scott@slp53.sl.home (Scott Lurndal): Oct 01 05:01PM >A CAS emulated by LL/SC isn't slower than a native CAS. >But atomic increments, decrements, ands, ors or whatever >ebulated with LL/SC is sometimes slower. Who said anything about CAS[*]? [*] For your edification, CAS on modern archtitectures isn't handled by the CPU, but rather by the point of coherency (LLC or PCI-Express/CXL endpoint). Something you can't do with LL/SC at all. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 01 12:54PM +0200 Ich wollte einfach mal die C-Funktion fmod() zur Berechnung des Divi- sions-Rests zweier doubles möglichst effizient in C++20 nachprogram- mieren. Ich hab das so hingekriegt, dass ca. 38% weniger CPU-Zeit benötigt als die glibc-Funktion. Grundsätzlich kann man nicht einfach hingehen und die Formel counter - trunc( counter / denominator ) * denominator nehmen, denn das ist zu un-präzise weil die Division ein Ergebnis haben kann das auf der ersten Vorkomma-Stelle gerundet wurde, weil niedrigwertige Vorkommastellen rechts von der Mantisse wegfallen oder weil bei er Multiplikation mit dem Nenner rechts wiederum Bits rechts von der Mantisse rausfallen. Das Besondere an fmod() ist eben, dass man das durchführt wie eine schriftliche Division, aber man merkt sich immer nur den Divisions -Rest. Der ist über alle Rechen-Schritte hinweg 53 Bits breit, d.h. das Ergebnis ist absolut exakt entsprechend den Parametern ! Ist doch irgendwie schräg, dass alle Standard FPU Operationen das inexact Bit setzen können wenn rechts von der Mantisse Einsen wegfallen, das aber so eine vergleichsweise komplexe Operation eben exakt ist. double myFmod( double divisor, double dividend ) { auto bin = []( double d ) -> uint64_t { return bit_cast<uint64_t>( d ); }; auto dbl = []( uint64_t u ) -> double { return bit_cast<double>( u ); }; auto invalid = [&]( uint64_t b ) -> double { feraiseexcept( FE_INVALID ); return dbl( b ); }; uint64_t bDivisor = bin( divisor ), bDividend = bin( dividend ); constexpr uint64_t SIGN_BIT = (uint64_t)1 << 63, EXP_MASK = (uint64_t)0x7FF << 52, IMPLCIT_BIT = (uint64_t)1 << 52, MANT_MASK = IMPLCIT_BIT - 1, QNAN_BIT = IMPLCIT_BIT >> 1; uint64_t sign = (bDivisor ^ bDividend) & SIGN_BIT; if( (bDivisor & EXP_MASK) == EXP_MASK ) [[unlikely]] // +/-[Inf|QNaN|SNaN] % ... = -QNaN // follow SSE/AVX-rules, first NaN rules return invalid( SIGN_BIT | bDivisor | QNAN_BIT ); if( (bDividend & EXP_MASK) == EXP_MASK ) [[unlikely]] // +/-x % +/-[Inf|QNan|SNaN] if( !(bDividend & MANT_MASK) ) [[likely]] // +/-x % +/-Inf = -/+x return dbl( SIGN_BIT | bDivisor & ~SIGN_BIT ); else // +/-x % +/-[QNaN|SNaN] = -NaN return invalid( SIGN_BIT | bDividend | QNAN_BIT ); int divisorExp = (bDivisor & EXP_MASK) >> 52, dividendExp = (bDividend & EXP_MASK) >> 52; uint64_t divisorMant = (divisorExp ? (uint64_t)1 : 0) << 52 | bDivisor & MANT_MASK, dividendMant = (dividendExp ? (uint64_t)1 : 0) << 52 | bDividend & MANT_MASK; auto normalize = []( uint64_t &v, int &exp ) { unsigned bits; #if defined(HAS_FIND_FIRST_ONE) bits = countl_zero( v ) - 11; v <<= bits; #else for( bits = 0; !(v & IMPLCIT_BIT); v <<= 1, ++bits ); 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment