|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On October 26 2014 03:34 Nesserev wrote:Show nested quote +On October 26 2014 03:18 teamamerica wrote:
Ya I guess I can't know what assumptions question had since I didn't ask - but assuming you can't buy-sell on same day, how would you handle that?
Well, if they don't want any losses and you can't buy-sell on the same day, then you could use this case (when buy and sell date are the same) to point out that you should never buy/sell. My approach won't handle the problem 'If you need to have a buy or sell date, even when the stock prices are continuously decreasing, what days would you pick to minimize your losses', but your approach should handle it just fine, I think, no?
Only approach I've seen so far that handles a continuously decreasing array, where you can't buy/sell on any day, must perform some buy/sell is the approach of iterating through the combinations. dae, you, and I had the same code basically, and that doesn't handle it. Anyway, I've honestly stopped working on that for now, I'm just checking this thread for updates as to other people attempted to solve it.
|
i already asked, what do you want to do in the case where buying on any day would result in a loss? not buy? minimize loss? it's literally an if statement for the first case
|
|
|
Lah-tech, as everyone else does. Your environment is weird.
|
Lah-tech by most people, lay-tech by some native English speakers. Definitely not tex however.
|
Lay-Tech and Latex (the brand) are the only pronounciations I've ever heard :| I guess it's the native English vs non-native difference for anyone who says it with a Lah?
|
On October 26 2014 08:45 Blisse wrote:
i already asked, what do you want to do in the case where buying on any day would result in a loss? not buy? minimize loss? it's literally an if statement for the first case
Sorry I've not made that clear - assume you're trying to minimize loss.
|
On October 25 2014 16:37 bangsholt wrote:Show nested quote +On October 25 2014 13:09 Blisse wrote:What does Microsoft.Net.Http offer over using System.Net.WebClient and System.Net.Http.HttpClient? Never really used the Microsoft.Net offering. I prefer using the JToken.FromObject and JToken.ToObject methods instead. Makes code much more portable I feel. I was referring to System.Net.Http.HttpClient ;o) Is JToken a standard interface of some sort, or why do you think it makes code more portable than JsonConverter? I mostly care about compatibility with Xamarin.
Oh I see. Yeah I feel like the Nuget and the System.Net.Http.Httpclient offering are the same o;
JTokens are serialized json objects represented as c# objects. Basically you do the step "JToken jObject = JToken.FromObject(myObject);", passing in a normal object (marked up with DataContract/JsonProperty/Xml attributes), and it converts it to a JToken(JObject/JArray). Passing around the JToken is heavier weight because the JToken internally is represented by an actual json dictionary (meaning jObject["attribute"] is a valid operation), but that also means calling "jObject.ToString()" is a very light operation because the json has already been serialized.
I said it's probably more portable because unlike with a JsonConverter, we don't have to implement a custom JsonConverter when we have to serialize stuff, or even initialize one. Instead, we mark up the actual object with attributes stating the conditions of the serialization/deserialization, and we only have to move the classes around if the project changes, not both the classes and converters. Makes for fewer dependencies.
The only problem is that if we want to have complicated serialization/deserialization logic, attribute markup tends to be hard to debug and long listed. In that case I would prefer using jsonconverter, but I think that keeping it in jtoken form first is preferable and only move over to jsonconverters when it's required.
|
On October 26 2014 10:10 Blisse wrote:
Lay-Tech and Latex (the brand) are the only pronounciations I've ever heard :| I guess it's the native English vs non-native difference for anyone who says it with a Lah?
How you change "la" to "lay" is beyond me. Tex as "tech" is because of this portion of the name is derived from Greek τέχ as in τέχνη (techne = art, skill).
In general, I'm reading it like that:
[L]-and
[A]-nthropomorphic
[T]-ime
[E]-ighty
[H]-elp
Here's how a greek pronounces τέχνη in μουσική τέχνη (music art): link
|
|
|
http://m.youtube.com/watch?v=0seJ3g8uFcQ
You guys do know that's there's a material called latex that's pronounced laytex right?
And youtubing latex really only gives me pronunciations of laytex (material) or laytech (document language)
|
|
|
Uh sooo, I'm confused and embarassed right now, but this :
void ft_putstr(char const *s);
char *ft_strclr(char *s)
{
int i;
i = 0;
while (s[i])
{
s[i] = '\0';
i++;
}
return (s);
}
int main(void)
{
char *str = "hello";
ft_putstr((char const *)str);
ft_putchar('\n');
str = ft_strclr(str);
ft_putstr((char const *)str);
ft_putchar('\n');
return (0);
}
segfault in the only loop there is and I can't for the life of me figure why. Yeah, I'm new to all that. Don't mind how weird/convoluted this may look, we have a strict set of rules at my school. "for" ? Forbidden. Built-in function ? Nah...
|
|
|
On October 26 2014 16:34 Cynry wrote:Uh sooo, I'm confused and embarassed right now, but this :
void ft_putstr(char const *s);
char *ft_strclr(char *s)
{
int i;
i = 0;
while (s[i])
{
s[i] = '\0';
i++;
}
return (s);
}
int main(void)
{
char *str = "hello";
ft_putstr((char const *)str);
ft_putchar('\n');
str = ft_strclr(str);
ft_putstr((char const *)str);
ft_putchar('\n');
return (0);
}
segfault in the only loop there is and I can't for the life of me figure why. Yeah, I'm new to all that. Don't mind how weird/convoluted this may look, we have a strict set of rules at my school. "for" ? Forbidden. Built-in function ? Nah...
So you're segfaulting when you try to change a string literal, which would usually be put into read-only, which is where you segfault comes from.
Solution 1:
+ Show Spoiler +So if you instead do,
char str[] = "hello";
char * str_ptr = str;
Now you allocate an array on the stack instead, (and probably do an implicit copy of "hello" from read-only) which can be manipulated. To satisfy the return value (which now is not used anymore), you need to add a pointer to a char - the str_ptr. and replace
str = ft_strclr(str);
with
str_ptr = ft_strclr(str);
It all works.
Solution 2:
+ Show Spoiler +You need to add two standard headers to use this.
#include <stdlib.h>
#include <string.h>
Then you change the following line
char *str = "hello";
to
/* 6 is length of "hello\n" */
char * str = calloc(sizeof(char), 6);
(void*) strncpy(str, "hello", 6);
Now it's instead a heap allocation, by using calloc, which again means you get a pointer back to where it has been allocated. Then the "hello" is copied into the piece of memory that is allocated, and everything works as intended. You should add a
free(str);
To make sure you don't leak memory now.
EDITs: Added explanation, added a second solution, removed extra tags
Silly learning examples are silly though ;o)
|
On October 26 2014 17:14 Nesserev wrote:
EDIT: Btw, why does your 'ft_strclr'-function return a char* ? Totally not necessary ... maybe an artefact from the code you had written before this?
This one I know the answer to - it's what you do with string functions in C, so that you can chain them 
A bad example, because I can't come up with a good use right now.
char * str = malloc(sizeof(char) * 100);
strncpy(memset(str, 0, 100), "hello world", 100);
Yes, the exact same thing would be accomplished by using calloc rather than malloc... But details ;o)
|
|
|
Your school sucks balls...
Haha, well, considering what you know about it it may be debatable (although I quite enjoy the "from the ground up" approach), but trust me, this school rocks ^^ It's called 42, a french school recently opened, look it up if you want. No teacher, no schedule, I quite like it there :D
Anyway, thanks ! Definitely sounds right, it's actually "something I'm supposed to already know" ^^
Yes, the *char returned is an artifact, wanted to try if my function worked by putting a letter instead of \0.
@bangsholt
Thank you too ! Wondering, how about :
char str[] = "hello";
str = ft_strclr(&str[0]);
Would that work ? Guess it should, gonna try when I get back to work.
Oh wow, just man-ed calloc. Allocate AND initiate ? Sounds useful, no wonder it's forbidden ><
So far we can only use write, malloc and free... Yup.
And yeah these are rather boring learning exemples, but we really have to do them, since our first assignement is to recode ~60 functions of libc, from putchar to atoi, so as to make our own library to use during the course. Everything else is, of course, forbidden. We'll eventually have our own printf, malloc etc.
Edit : Calloc can initiate to something else than 0 ?? Oh my...
Edit 2 : What I wondered about doesn't work.
ft_strclr.c: In function ‘main’:
ft_strclr.c:22:6: error: incompatible types when assigning to type ‘char[6]’ from type ‘char *’
str = ft_strclr(&str[0])
Doesn't matter to finish this function, but I'm still curious as to why. There shouldn't be a char[6] with a 6 char long string, and the while in strclr should stop at [5] as it's a \0. What am I missing ?
|
On October 26 2014 18:33 Cynry wrote:@bangsholt Thank you too ! Wondering, how about : char str[] = "hello";
str = ft_strclr(&str[0]);
Why are you passing the address of index 0 of str?
Passing str would do the same. This is one of the cases where an array is the same as a pointer.
On October 26 2014 18:33 Cynry wrote:Edit 2 : What I wondered about doesn't work. ft_strclr.c: In function ‘main’:
ft_strclr.c:22:6: error: incompatible types when assigning to type ‘char[6]’ from type ‘char *’
str = ft_strclr(&str[0]) Doesn't matter to finish this function, but I'm still curious as to why. There shouldn't be a char[6] with a 6 char long string, and the while in strclr should stop at [5] as it's a \0. What am I missing ?
And here is a case of an array not being the same as a pointer.
One way to view the use of a string literal, is that it will be expanded into something like this
char[6] str = {'h', 'e', 'l', 'l', 'o', '\0'};
That's where your char[6] comes from.
Why do you think that where the while loop stop holds any significance?
|
I thought that
char str[] = "hello";
ft_strclr(&str[0]);
would be equivalent to
char *str = "hello";
ft_strclr(str);
would be the same except that I would be able to modifiy the string in the first exemple, avoiding the error that brought me here in the first place because of the second exemple.
And here is a case of an array not being the same as a pointer.
One way to view the use of a string literal, is that it will be expanded into something like this
char[6] str = {'h', 'e', 'l', 'l', 'o', '\0'};
That's where your char[6] comes from.
Why do you think that where the while loop stop holds any significance?
I misinterpreted the error. Thought that char[6] pointed to the 7th character (starting at char[0]) and that the while loop was responsible for the error, trying to go too far or something like that (would have been another segfault I guess).
Now if I understand correctly, char[6] simply is an array of 6 char, \0 included, and the error comes from the fact that ft_strclr returns a char *. Correct ?
|
|
|
|
|
|
EPT
