Develop Reference

How to print a text using "pixels" [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm using a fitness tracker with a watchface store - some of this watchfaces print the current time using other elements than simple text.
A few months ago I tried to beat a challange in "Coding game" where you have to print dynamic text in ascii art - I didn't manage to do that :(
I'm assuming that the basic technique should be the same but I cannot think about how to do it. May anyone tell me how to print e.g. the current time using dots / squares?
My last approach was to define a two dimensional array for each possible character, bitwise defining which spot should be active or inactive. But as this is pretty hard work I discarded that really quick.
Thanks for your help.

Actually, you were on the right track. That's one way to do it - a 2D array for each character with the bitmask. Or better yet - a full ASCII picture. Takes some work upfront, but not that much - you can probably do it in a day or two. You can also simplify the typing a bit. Like this:
Dictionary<char, string[]> = {
{'A', new string[] {
" AAAA ",
"AA AA",
"AAAAAA",
"AA AA",
"AA AA"
}},
// etc. for all characters in your "ASCII font"
}
Another way would be to define some sort of "vector format" for your characters, scale it to be as big as you need, and then convert to ASCII with some sort of algorithm that uses the characters -|/\. for outlines. That's much harder, and you still need to describe every character individually. But it looks prettier.
Or take a look at this answer: https://stackoverflow.com/a/7239064/41360 - that actually uses a bitmask. Yes, it probably took someone a few days to get it right. Harder than the string approach above, but also more compact if you're short on space (like in some embedded hardware).
And then there's Figlet - that piece of software has gone all the way and defined its own font format, not to mention some sort of advanced text rendering engine which actually merges the characters together. Crazy shit.
But no matter what approach you use, someone somewhere will need to design each letter individually and store the designs in some kind of format (thus producing a "font"). Most likely it will be you. There's no way around it.
Programmers might be lazy and use tricks to make their lives easier - but sometimes hard work is simply unavoidable. When that comes, you just do it. At the end of the day, it's the result that counts, not how it was obtained (well, as long as it's ethical/legal of course).

Can you speed up this algorithm? C# / C++ [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Hey I've been working on something from time to time and it has become relatively large now (and slow). However I managed to pinpoint the bottleneck after close up measuring of performance in function of time.
Say I want to "permute" the string "ABC". What I mean by "permute" is not quite a permutation but rather a continuous substring set following this pattern:
A
AB
ABC
B
BC
C
I have to check for every substring if it is contained within another string S2 so I've done some quick'n dirty literal implementation as follows:
for (int i = 0; i <= strlen1; i++)
{
for (int j = 0; j <= strlen2- i; j++)
{
sub = str1.Substring(i, j);
if (str2.Contains(sub)) {do stuff}
else break;
This was very slow initially but once I realised that if the first part doesnt exist, there is no need to check for the subsequent ones meaning that if sub isn't contained within str2, i can call break on the inner loop.
Ok this gave blazing fast results but calculating my algorithm complexity I realised that in worst case this will be N^4 ? I forgot that str.contains() and str.substr() both have their own complexities (N or N^2 I forgot which).
The fact that I have a huge amount of calls on those inside a 2nd for loop makes it perform rather.. well N^4 ~ said enough.
However I calculated the average run-time of this both mathematically using probability theory to evaluate the probability of growth of the substring in a pool of randomly generated strings (this was my base line) measuring when the probability became > 0.5 (50%)
This showed an exponential relationship between the number of different characters and the string length (roughly) which means that in the scenarios I use my algorithm the length of string1 wont (most probably) never exceed 7
Thus the average complexity would be ~O(N * M) where N is string length1 and M is string length 2. Due to the fact that I've tested N in function of constant M, I've gotten linear growth ~O(N) (not bad opposing to the N^4 eh?)
I did time testing and plotted a graph which showed nearly perfect linear growth so I got my actual results matching my mathematical predictions (yay!)
However, this was NOT taking into account the cost of string.contains() and string.substring() which made me wonder if this could be optimized even further?
I've been also thinking of making this in C++ because I need rather low-level stuff? What do you guys think? I have put a great time into analysing this hope I've elaborated everything clear enough :)!

Your question is tagged both C++ and C#.
In C++ the optimal solution will be to use iterators, and std::search. The original strings remains unmodified, and no intermediate objects get created. There won't be an equivalent of your Substring() taking place at all, so this eliminates that part of the overhead.
This should achieve the theoretically-best performance: brute force search, testing all permutations, with no intermediate object construction or destruction, other than the iterators themselves, which simply replace your two int index variables. I can't think of any faster way of implementing this basic algorithm.

Are You testing one string against one string? If You test bunch of strings against another bunch of strings, it is a whole different story. Even if You have the best algorithm for comparing one string against another O(X), it does not mean repeating it M*N times You would get the best algorithm for processing M strings against N.
When I made something simmiliar, I built dictionary of all substrings of all N strings
Dictionary<string, List<int>>
The string is a substring and int is index of string that contains that substring. Then I tested all substrings of all M strings against it. The speed was suddenly not O(M*N*X), but O(max(M,N)*S), where S is number of substrings of one string. Depending on M, N, X, S that may be faster. I do not say the dictionary of substrings is the best approach, I just want to point out that You should always try to see the whole picture.

Using Keys Enumeration or Ascii code is better in-terms of good programming? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Please provide me view on below code.. on option 1 and option 2 to use for better programming practices in C#.
private void textBox1_KeyDown(object sender, System.Windows.Forms.KeyEventArgs e)
{
// Option 1
if (e.KeyCode == Keys.Enter )
{
// some code
}
//Option 2
if (e.KeyCode == (char)13)
{
// some code
}
}

Picture this: it's late at night and you are looking through this code, you get to that line, and wonder: what exactly does 13 mean? Is that 13 decimal, or 13 hexadecimal? What if it was 41 - what does that mean?
It all comes down to code maintainability - using a preset enumeration (especially when its already provided for you, no work required) is far more maintainable and readable than straight ASCII codes.
Sure, the ASCII codes work and they are old skool and bad ass, but the enumeration reduces any chance of misunderstanding what was intended.

It is obvious that option 1 is more readable.
Use Enums whenever you can.
It is in general not a good practise to use numbers direct in your source code.
So if you have no enums at hand or do not want to create your own, instead of doing something like this:
if (myObject.Position.X > 25)
better do this:
int leftBorder = 13;
if (myObject.Position.X > leftBorder)
This might not seem so important at the first glance but as a developer you sometimes see code like this
mObj.SetVl = Global.iValue + 27 - (Global.uValue * 2);
Happy guessing what 27, 2, iValue etc means :).
It is important to give your variables meaningfull names and not to use lose numbers or strings etc. in your source code.

Option 1 that is if (e.KeyCode == Keys.Enter) is better:
It's easier to read, e.g. what's (char) 27 or (char) 9? Keys.Escape is evident
Characters and keys are not in one-to-one relation, e.g. character '1' can be result from either Keys.D1 or Keys.NumPad1

Option 1 is cleaner and much easier to read. There is no reason why you'd want to cast the numeric value like that.

Use option 1:
It is cleaner
It is easier to read
It will still work if the numerical value should change at some point in the future.

Is using LINQ against a single object considered a bad practice? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I don't mean this question to be too subjective.
I google'd this for some time but got no specific answers to address this issue. The thing is, I think I'm getting somewhat addicted to LINQ. I already used LINQ to query on lists among other things like using Linq to Sql, Xml, and so on. But then something struck me: "What if I used it to query a single object?" So I did. It may seem wrong like trying to kill a fly with a grenade launcher. Though we all agree it would be artistically pleasant to see.
I consider it very readable, I don't think there is any performance issues regarding to this, but let me show you an example.
In a web application, I need to retrieve a setting from my configuration file (web.config). But this should have a default value if the key is not present. Also, the value I need is a decimal, not a string, which is the default return from ConfigurationManager.AppSettings["myKey"]. Also, my number should not be more than 10 and it should not be negative. I know I could write this:
string cfg = ConfigurationManager.AppSettings["myKey"];
decimal bla;
if (!decimal.TryParse(cfg,out bla))
{
bla = 0; // 0 is the default value
}
else
{
if (bla<0 || bla>10)
{
bla = 0;
}
}
Which is not complicated, not convoluted, and easy to read. However, this is how I like it done:
// initialize it so the compiler doesn't complain when you select it after
decimal awesome = 0;
// use Enumerable.Repeat to grab a "singleton" IEnumerable<string>
// which is feed with the value got from app settings
awesome = Enumerable.Repeat(ConfigurationManager.AppSettings["myKey"], 1)
// Is it parseable? grab it
.Where(value => decimal.TryParse(value, out awesome))
// This is a little trick: select the own variable since it has been assigned by TryParse
// Also, from now on I'm working with an IEnumerable<decimal>
.Select(value => awesome)
// Check the other constraints
.Where(number => number >= 0 && number <= 10)
// If the previous "Where"s weren't matched, the IEnumerable is empty, so get the default value
.DefaultIfEmpty(0)
// Return the value from the IEnumerable
.Single();
Without the comments, it looks like this:
decimal awesome = 0;
awesome = Enumerable.Repeat(ConfigurationManager.AppSettings["myKey"], 1)
.Where(value => decimal.TryParse(value, out awesome))
.Select(value => awesome)
.Where(number => number >= 0 && number <= 10)
.DefaultIfEmpty(0)
.Single();
I don't know if I'm the only one here, but I feel the second method is much more "organic" than the first one. It's not easily debuggable, because of LINQ, but it's pretty failproof I guess. At least this one I wrote. Anyway, if you needed to debug, you could just add curly braces and return statements inside the linq methods and be happy about it.
I've been doing this for a while now, and it feels much more natural than doing things "line per line, step by step". Plus, I just specified the default value once. And it's written in a line which says DefaultIfEmpty so it's pretty straightforward.
Another plus, I definitely don't do it if I notice the query will be much larger than the one I wrote up there. Instead, I break into smaller chunks of linq glory so it will be easier to understand and debug.
I find it easier to see a variable assignment and automatically think: this is what you had to do to set this value, rather than look at ifs,elses,switches, and etc, and try to figure out if they're part of the formula or not.
And it prevents developers from writing undesired side effects in wrong places, I think.
But in the end, some could say it looks very hackish, or too arcane.
So I come with the question at hand:
Is using LINQ against a single object considered a bad practice?

I say yes, but it's really up to preference. It definitely has disadvantages, but I will leave that up to you. Your original code can become much simpler though.
string cfg = ConfigurationManager.AppSettings["myKey"];
decimal bla;
if (!decimal.TryParse(cfg,out bla) || bla < 0 || bla > 10)
bla = 0; // 0 is the default value
This works because of "short circuit" evaluation, meaning that the program will stop checking other conditions once the first true condition is found.

Delimited string parsing? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking at parsing a delimited string, something on the order of
a,b,c
But this is a very simple example, and parsing delimited data can get complex; for instance
1,"Your simple algorithm, it fails",True
would blow your naiive string.Split implementation to bits. Is there anything I can freely use/steal/copy and paste that offers a relatively bulletproof solution to parsing delimited text? .NET, plox.
Update: I decided to go with the TextFieldParser, which is part of VB.NET's pile of goodies hidden away in Microsoft.VisualBasic.DLL.

I use this to read from a file
string filename = #textBox1.Text;
string[] fields;
string[] delimiter = new string[] {"|"};
using (Microsoft.VisualBasic.FileIO.TextFieldParser parser =
new Microsoft.VisualBasic.FileIO.TextFieldParser(filename)) {
parser.Delimiters = delimiter;
parser.HasFieldsEnclosedInQuotes = false;
while (!parser.EndOfData) {
fields = parser.ReadFields();
//Do what you need
}
}
I am sure someone here can transform this to parser a string that is in memory.

A very complrehesive library can be found here: FileHelpers

I am not aware of any framework, but a simple state machine works:
State 1: Read every char until you hit a " or a ,
In case of a ": Move to State 2
In case of a ,: Move to State 3
In case of the end of file: Move to state 4
State 2: Read every char until you hit a "
In case of a ": Move to State 1
In case of the end of the file: Either Move to State 4 or signal an error because of an unterminated string
State 3: Add the current buffer to the output array, move the cursor forward behind the , and back to State 1.
State 4: this is the final state, does nothing except returning the output array.

Such as
var elements = new List<string>();
var current = new StringBuilder();
var p = 0;
while (p < internalLine.Length) {
if (internalLine[p] == '"') {
p++;
while (internalLine[p] != '"') {
current.Append(internalLine[p]);
p++;
}
// Skip past last ',
p += 2;
}
else {
while ((p < internalLine.Length) && (internalLine[p] != ',')) {
current.Append(internalLine[p]);
p++;
}
// Skip past ,
p++;
}
elements.Add(current.ToString());
current.Length = 0;
}

There are some good answers here: Split a string ignoring quoted sections
You might want to rephrase your question to something more precise (e.g. What code snippet or library I can use to parse CSV data in .NET?).

To do a shameless plug, I've been working on a library for a while called fotelo (Formatted Text Loader) that I use to quickly parse large amounts of text based off of delimiter, position, or regex. For a quick string it is overkill, but if you're working with logs or large amounts, it may be just what you need. It works off a control file model similar to SQL*Loader (kind of the inspiration behind it).

Better late than never (add to the completeness of SO):
http://www.codeproject.com/KB/database/CsvReader.aspx
This one ff-ing rules.
GJ

I am thinking that a generic framework would need to specify between two things:
1. What are the delimiting characters.
2. Under what condition do those characters not count (such as when they are between quotes).
I think it may just be better off writing custom logic for every time you need to do something like this.

Simplest way is just to split the string into a char array and look for your string determiners and split char.
It should be relatively easy to unit test.
You can wrap it in an extension method similar to the basic .Spilt method.