|
One of my old friends, Mihai Chis [^], is a world-class C# programmer in Bucharest, and I bet there are other resources. In Bulgaria, a group of C# programmers published an excellent, free, guide to programming in C# (English available): [^].
You can search CP for recommendations on other books by several people, including me: [^]
cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Thank You ! 
|
|
|
|
|
if you want to continue the discussion, keep in touch add me on skype: yamato yammy
|
|
|
|
|
I guess some regex guru could come up with a solution far less readable than this one!
|
|
|
|
|
That's why I suggested translation arrays - you can add the characters you want and the code doesn't change:
private const string transA = "abcdefghijklmnopqurstuvwxyz0123456789";
private const string transB = "bcdefghijklmnopqurstuvwxyza9876543210";
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
oh, now i understand what this trans do, thank you. It works with this method, I will try the other method with select and I will put it here
|
|
|
|
|
And you use the same code but with transA and transB swapped over to decode it.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Now that the OP is slowly revealing more and more complexity in the substitution rules ... this approach makes more and more sense to me 
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
I learned many years ago that the only constant in this profession is that everything changes! 
So I always try to code for alterations, by using the most flexible solution available.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Okay then, I won't mention Heraclitus: "panta rhei"
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Quote: τὰ πάντα ῥεῖ καὶ οὐδὲν μένει
I didn't say it was an original philosophy, just an OriginalGriff philosophy!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I didn't say it was UnOriginalGriff 
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
modified 27-May-19 6:48am.
|
|
|
|
|
Constants ain't!
Variables won't!
... That is an old truth from at least 30 years ago. I haven't been thinking of it for years (or heard others refer to it). Maybe I should have a t-shirt made with that text.
|
|
|
|
|
Many. many years ago I worked with a FORTRAN compiler that passed by reference. So you could do the equivalent of this:
void AddTen(int val)
{
val += 10;
}
...
x = 666;
AddTen(x);
Console.WriteLine($"{x} == {666}?");
x = 666;
AddTen(666);
Console.WriteLine($"{x} == {666}?");
x = 666;
Console.WriteLine($"{x} == {666}?");And you would get the output
676 == 666?
666 == 676?
676 == 676? As the constant value had been changed for ever more ...
Debugging was a mans game back then!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Just wait until he comes with the Chinese alphabet
|
|
|
|
|
With a little LINQ magic:
string outputString = new string(inputString.Select(c => (c >= 'a' && c <= 'z' ?
(char)('a' + (c - 'a' + 1) % 26) : c)).ToArray());
|
|
|
|
|
Coding discussions like these brings up the nostalgia in me, about the old days of Pascal, where array indexes could be of arbitrary discrete types, arbitrary lower and upper limits. Like an array indexed from 'a' through 'z'.
And also: Discrete types have a natural ordering, not because they "really are integers", because they are not. Succ('a') is 'b', without casting to int, increment and cast back. Wednesday follows Tuesday. And so on.
Proper handing of enums and discrete subrange types is near the top of my wish list for future C# versions. They could do it in Pascal 49 years ago; it should be possible to do in C# today. But it seems like I am the only one missing it. (Or maybe: One of the very few to know that once it existed.)
|
|
|
|
|
Dear experts
I'm migrating some stuff from c++ (Borland Builder) to c#.
While comparing the calculations between the two implementations I found among others
a.) c++: pow(0.1, 3.0) results in 0.001
b.) c#: Math.Pow(0.1, 3.0) results in 0.0010000000000000002
Ok so far so good. "power" is not an fpu instruction and therefore I can imagine that the two results are slightly different, because of maybe different implementation of the "power" function.
Nevertheless I made the following experiment
c++: double test= 0.1 * 0.1 * 0.1 which results in 0.001
c#: double test= 0.1 * 0.1 * 0.1 which results again in 0.0010000000000000002
Surprising for me
The latter now is something surprising -at least for me- because I'm assuming that both (c++ and c#) will use the fpu for multiplications.
I googled a lot for this, but I'm not able to find an explanation. Do you have an idea?
Thank you very much in advance for your comments on this.
Regards
[edit]
Btw: I also tried _clearfp and _fpreset for c#, but results remain the same.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
The default precision to which doubles are printed is different in C++ and C#, so they might actually be the same, can't tell from this. They might also be different, depending on some funny combination of one program being 32bit (and defaulting to the x87 FPU and 80bit computation followed by a conversion to 64bit) and the other 64bit (and defaulting to SSE2 and 64bit computation), I'm not sure if that actually makes a difference here.. If you reinterpret the bits as an int64 and print that we could be sure.
|
|
|
|
|
|
0x01AA wrote: I think ten years ago I would also have come up with the idea to compare the results binary
Also, the neatness the C++ result would have made a ring bell[^]. 
|
|
|
|
|
Thank you very much for this great link 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Makes me think of when I was playing around with APL: No distinction between int and float, no explicit declaration of type. All numerics were 64 bit FP.
To avoid problems with values that conceptually are the same, but due to limited precision may not be (such as 1/3 + 1/3 + 1/3 not necessarily being identical to 1.0), there was a user settable tolerance variable - if my memory is right, it was called quadFUZZ): In any comparing of numerics, if the difference was less that FUZZ, the values were treated as exactly equal. I believe something similar also exist in other highly environments, such as Smalltalk.)
I was teaching C++ programming for a few years. Any hand-ins where float variables were compared by == to constants or othter varibles did not pass. My teaching was to consider == an invalid operator for floats - use >, >=, <, <=. And where appropriate, code the APL style in longhand: if (abs(f1-f2) < fuzz) { ... treat as exactly equal.
Of course some students objected: "Why can't we just ...", and I had to explain over and over. One student went as far to hand in a homework which stared with a big block comment, headed by: "This is how REAL PROGRAMMERS would code the solution: ..." and after som real dirty code, at the end of the comment block: "But this is how our professor forces us to do it: " - and then some clean and readble code, not commented out. So he knew how to behave in a disciplined way, but refused do give up his undisciplined behaviour completely. 
|
|
|
|
|
Thank you for your reply. But I was never trying to do something like a==b, I was comparing the two implementations.
Btw:
I would never do a==b for double values, instead I do !(a<b) && !(a>b) And no, of course I also don't do that
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Back in the day, I wrote a method called AlmostEqual to compare floating point values to a specified precision. I've found that as long as you don't do math on the value, it will remain as it was set, so given the following:
double x = 0.01d;
double y = 0.01d; The expression if (x == y) will always evaluate to true.
However, if you to this:
x = x * 1.0d the expression above will evaluate to false.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
More and more I recognize I'm becoming older...