Activity for nsajko
-
nsajko committed [263b39]
Geodesic: improve A1m1f, A2m1f, C1f, C1pf, C2f
-
Clang, on the other hand, also has that option, but with a different default.
-
Regarding FMA, whether it will improve accuracy depends on the target architecture and on the compiler. With GCC, for example, there should probably be no change because GCC optimizes to FMA automatically by default, unless -ffp-contract=off is specified.
-
I should have mentioned that I'm only interested in the double case, that is GEOGRAPHICLIB_PRECISION == 2.
-
Hello, I'm currently working on slightly improving the accuracy and/or speed of the Geodesic::A1m1f, Geodesic::A2m1f, Geodesic::C1f, Geodesic::C1pf, Geodesic::C2f functions, and possibly others. What's the best way to test that my changes actually improve accuracy or that the changes don't degrade accuracy?
-
GeographicLib::Constants: fix WGS84 flattening definition
-
Just by looking at some GCC warnings, I'm 95% sure PractRand (0.94 + pre0.95) has some easily fixable but possibly quite serious bugs. I'm willing to contribute fixes, but it's really not clear what's the process for that. I'm a bit put off by the possibility that the bugs are already fixed in some unreleased version, because, as far as I understand, there is no development version available after pre0.95. Do you have something unreleased you're working on? How would you feel if I imported 0.94 and...
-
Just by looking at some GCC warnings, I'm 95% sure PractRand (0.94 + pre0.95) has some easily fixable but possibly quite serious bugs. I'm willing to contribute fixes, but it's really not clear what's the process for that. I'm a bit put off by the possibility that the bugs are already fixed in some unreleased version, because, as far as I understand, there is no development version available after pre0.95. Do you have something unreleased you're working on? Also, are there plans to switch to Git?...
-
Hello, In the header tools/MultithreadedTestManager.h, a member function called retire has volatile return type. I guess the intention was to prevent some compiler optimization? Whatever the intention was, it's not being served by having a volatile return value: that construction in the type signature has no meaning, i.e., the semantics are the same as if the volatile keyword was omitted. I.e., the compiler just ignores it. So you probably have a bug there somewhere. Also, AFAIK C++20 disallows having...
-
In the end I computed power dissipated on the resistor r1 in three different ways just to be sure: r1 0 1 ... define power(x, y) real((x) * conj((y))) ac lin 1 1 1 print mag(i(v0))^2 * @r1[resistance] print mag(v(1))^2 / @r1[resistance] print power(v(1), i(v0)) BTW, my circuit only has linear components.
-
Excuse my ignorance I am surely still missing something: So you are saying that @device[p] should not be used at all with .AC? Or maybe you are saying that it can not be correct in general? I could certainly uderstand that considering that in the very manual section title AC is called "Small-Signal AC Analysis". But in the case of only using linear components in the simulation, could it still not be made to work correctly?
-
I do not know if I can edit the bug report above, but there is an error in my bug report, sorry about that. The correct formula as far as I know is not abs(real(voltage * current)) as I said above, it is real(voltage * conj(current)), which is real(voltage * (real(current), -imag(current)))
-
Could you expand this comment, maybe give an example; I do not understand it. For what it is worth I think representation of AC power as a complex number is (just as with voltage and current) standard practice for longer than SPICE exists ...
-
I do not know if I can edit the bug report above, but there is an error in my bug report, sorry about that. The correct formula as far as I know is not abs(real(voltage * current)) as I said above, it is abs(real(voltage * conj(current))), which is abs(real(voltage * (real(current), -imag(current))))
-
Incorrect calculation of device instance parameter power for AC analysis
-
ecu_connect: remove unused variable
-
Rename types with names reserved by POSIX
-
Add schedSetter, a program to exec scantool and set its scheduling
-
Remove some unused declarations
-
Add curly brackets around single statements for readability
-
Remove redundant casts
-
Remove redundant elses
-
cosmetic: Put a space after if, switch, while, for keywords
-
wait_enter: Make format string a constant
-
cosmetic: Consistently cuddle '}' and 'else'
-
cosmetic: Consistently use whitespace around curly brackets
-
cosmetic: Put '*' adjacent to the identifier and not to the type
-
Automated esniper bug report.
1