Activity for nsajko
-
nsajko modified a comment on merge request #11
First point: Parameter range is defined in the Sollya script that is supposed to be saved to /tmp/polynomials.sollya. This is the one generated by print_poly_from_coefficients.cc, so that's where the definition is (lines 115 to 123): https://gitlab.com/nsajko/geodesic_experiments_for_geographiclib/-/blob/main/src_print_poly/print_poly_from_coefficients.cc#L115 So there is dom for A1 and A2, and dom2 for C1, C1p, C2. The range dom is defined again for the random generator functions, as discussed in...
-
One thing that I should have noted somewhere in the README on the Gitlab repo is that the C++ code in that repo is C++20, tested with GCC 11. And I know for a fact that it uses multiple features which are not yet supported by Clang.
-
First point: Parameter range is defined in the Sollya script that is supposed to be saved to /tmp/polynomials.sollya. This is the one generated by print_poly_from_coefficients.cc, so that's where the definition is (lines 115 to 123): https://gitlab.com/nsajko/geodesic_experiments_for_geographiclib/-/blob/main/src_print_poly/print_poly_from_coefficients.cc#L115 So there is dom for A1 and A2, and dom2 for C1, C1p, C2. The range dom is defined again for the random generator functions, as discussed in...
-
As noted in the repo linked from the commit message, there is a sort of issue with the rand0 relative error measurements: I don't understand how such results are possible (for rand0 only). Another issue that requires more thinking about is that this change set optimizes for WGS84, so it's no good for ellipsoids very different from it. So maybe you'd want to guard this changeset with a new macro, perhaps named GEOGRAPHICLIB_OPTIMIZE_FOR_WGS84.
-
Max relative errot plots (see the URL in the commit message):
-
-
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
-
Ah, sorry, I assumed too much about the type T. Now I know that depending on the value of GEOGRAPHICLIB_PRECISION my change isn't good. Would it perhaps make sense to do something like: #if GEOGRAPHICLIB_PRECISION <= 3 return T(3.35281066474748071984552861852e-3); #else return 1 / ( T(298257223563LL) / 1000000000 ); #endif
-
Ah, sorry, I assumed too much about the type T. Now I know that depending on the value of GEOGRAPHICLIB_PRECISION my change isn't good. Would it perhaps make sense to do something like: #if GEOGRAPHICLIB_PRECISION < 3 return T(3.35281066474748071984552861852e-3); #else return 1 / ( T(298257223563LL) / 1000000000 ); #endif
-
This is my first time using Git on Sourceforge, BTW, I hope I didn't do something wrong.
-
GeographicLib::Constants: fix WGS84 flattening definition
-
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