/dpt/ - Daily Programming Thread

What are you working on, Sup Forums?

Old thread:

Other urls found in this thread:

megaprocessor.com/index.html
github.com/ansuz/RIIR/issues/1
twitter.com/SFWRedditImages

Null-terminated byte arrays

wannacry v2.0

Remember that the best programmers work with the best languages.

>god tier
2^n
>top tier
n
>high tier
m/2^n
>meh tier
m/n
>shit tier
irrational numbers
>oh shit nigga what are you doing tier
complex numbers

>not even shitty enough to be ironic

let's all love lain

That just reflects the opposite of your random opinion, not anything funny or relatable.

Also check out megaprocessor.com/index.html . The guy has a youtube channel where he explains everything.

any phycicist here i have a quick simple question

What do you want?

Why are general CPUs so bad at dealing with floating-point calculations?

They are?

Albert Einstein here, AMA.

your mom

kek

Yes, that's why FPUs exist

FPUs go in the CPU

is this a correct way to describe projectile motion in 3d
here is the formulas
Vx(t) = Vxo - drag*t
Vy(t) = Vyo - g*t- drag*t
Vz(t) = Vzo - drag*t


X(t) = Vx(t)*t+Xo
symmetric formula for y and z dimensions

People still use FPUs as coprocessors?

>he doesn't know about AVX2

> 2^n is god tier
> complex numbers below shit tier
> powers of 2 are a subset of C.

Learn maths please, user.

Are you ready for that huge salary, /dpt/?

>euler integration
absolutely disgusting

Given an arbitrary system of equations, why is direction in space "stored" in the variables when considering the system as linear equations, but "stored" in vectors when considering the system as a vector equation? For example suppose we have a system of three equations in three variables where each equation is of the form (a_i)x + (b_i)y + (c_i)z = d_i. Lets also suppose they represent three distinct planes in R^3 (so we have linear independece). In the context of the system representing planes in space, it seems to me that dimension/direction is sort of "stored" in the variables x, y and z.
Considering the system now as a linear combination of vectors, the coefficients associated with any one variable make a column vector. The vector equation associated with the system would then be xv_1 + yv_2 + zv_3 = . In this context it seems as though dimension/direction is stored in the vectors, and the variables x,y, and z now just scale them.
It is even more strange to me that these three planes can also be defined as vector equations by dotting the normal vectors with a vector parallel to the given plane and setting it equal to 0
Back to the original question, I realize that both contexts have the same solution set, and both take place in R^3, but is there a more intuitive explanation for this relatedness?

Any physicists here? I want to kick your ass.

Can unresolvable circular dependencies exist (in C)?

I used to be really into functional reactive programming but looking back I have no idea why.

>maths
like i'm going to listen to sumone who can't even proper english lmao
2/10 made me replie

>Can unresolvable circular dependencies exist (in C)?
Not sure what you're even asking. You can have whatever circular dependencies you want. Just use forward declaration.

My current coding project is driving a small OLED display from the GPIO of a raspberry pi zero,

Any anime lolis here? I want to sniff you

Show me your General Lambert's Problem Solver.

aha so you agree with the equations
whether a vector or just 3 equations literally doesn't matter conceptually, it's basically the same thing

maybe you'd have me write fucking vectors in my post or what
anyways i got what i wanted, ty

You're right that this is retarded, but the solution would be to invalidated that syntax rather than changing the meaning.

int *i, j

Perfectly represents what's happening. That *i and j are both integers.

best program ever

>Perfectly represents what's happening.
It doesn't, and the reason has already been explained half a dozen times by now. If you're too much of a brainlet to grasp it, that's your problem.

So you are saying that
>That *i and j are both integers.
is wrong?

That sounds pretty lewd, user-kun.

how can I keep my functions organized? Basically I have one huge loop that looks like this:

class 1
big loop {
call class 1 function 1
call class 1 function 2
}

class 2
function 1: login
function 2: another loop{
get data
if data requires further analysis call class 3 function 1
}

class 3
function 1: analyze data. if data is viable send it to function 2
function 2: send analyzed data back to server

and basically each function is about 150 lines of code. I'm just having trouble keeping it organized because the functions are iterative, you can't send all the data back to the first class and control it all from there because each data point in class 2 function 2 has to go to class 3 in an iterative fashion.

idk if I'm making sense but there you have it
I know I could control it all from one loop but I don't know if that would be worth the investment of time really

Can we agree that int* i; and int *i both make sense but the former is simply more clear and scalable?

Correct, if only that's how the language actually worked.

shit I meant
*call class 2 function 1, etc.

for the functions in class 1

github.com/ansuz/RIIR/issues/1
I love this

In theory. If you're talking about C specifically then only the latter makes sense.

Personally I prefer x: *T to either of those.

Can't we all agree that *int i; is the one true path?

I am saying that this is completely irrelevant. "int *i;" takes part of the type descriptor and glues it to the name, breaking the established pattern that the type descriptor comes first, and the name comes second. This is the objective fact of the matter. Your opinion about the helpfulness of this inconsistency is a purely subjective matter. The objective fact is that it causes an inconsistency that doesn't make sense to everyone.

Now this is patrician.

I don't like the identifier: type style but otherwise, perfect.

That's not valid C you dumbfuck.

You're not saying anything about how it doesn't perfectly represent what is happening. In a variable declaration, the fact that something is a pointer is part of the name. End of story. It's unfortunate, but that's how it works.

It's the best option if you want type inference. Otherwise you need something like "auto" because there's no indicator of whether the type is present or not for parsing (: serves that purpose).

>You're not saying anything about how it doesn't perfectly represent what is happening
It doesn't perfectly represent what is happening, because *i represents dereferencing i, and what's actually happening is that a variable named i is defined, and that variable has the type int*. You are mentally retarded, your opinion is inherently invalid and this discussion is closed.

Saying "i is an int*" is the same as saying "*i is an int".

I see your point, and that can lead to the rather elegant inferred := foo(); explicit: type = foo(); style.
But I'm not sure I'm still entirely sold on it. In the end I don't think it matters very much.

>Saying "i is an int*" is the same as saying "*i is an int".
It literally isn't, you fucking cripple, because the definition of variable i is about the variable i, not about the value held in the address held by variable i.

>not writing your own compiler

int *ptr = malloc(sizeof *ptr);
ptr = malloc(sizeof *ptr)
defend this inconsistency

Correct, you are defining a variable i and saying that *i is an int, which means i is an int*. It's rather roundabout but there's no misrepresentation.

I won't, because there was no mention of assignment in the discussion before this.

>declaring an int should look like this: *0=0 i, because this represents exactly what happens when you do i*0
This is literally what you're saying.

This. The strict aliasing rule can get fucked.

strict aliasing is fine nigger, lrn2 use unions

>*0=0 i;
You are defining a variable named i and saying that i*0=0, which means i is an int. It's rather roundabout but there's no misrepresentation.

This is just turning into insane rambling at this point.

this is why you shouldn't try to grok C

Everyone except you

What was it you were after?

But it's literally your proposal. You're the one unironically insisting we should do exactly that.

Where?

I'm mocking the kid who I responded to. The strict aliasing rule implies that the address held by variable is only for derefrencing ints. So yes, they are the same, implies otherwise means that address can be used for other purposes, which is UB.

when you suggest that it's reasonable to declare something by what happens when you use it rather than by what it is.

I real human beings can solve the halting problem, why can't programs?
Checkmate computer "scientists"

I didn't say it was reasonable, I said it was valid. And it was only in reference to type.

Because you don't understand the meaning of the halting problem.

Let's review your argument:
>int *i; is appropriate because it describes what happens when you dereference 'i' (you get an int), and from this you can deduce that the type of 'i' is a pointer to an int
>*0=0 is appropriate because it describes what happens when you multiply 'i' by the integer 0 (you get an integer 0) and from this you can deduce that they type of 'i' is an int
This is your logic, not mine.

First of all, the latter statement is false. Second of all, I didn't say it and it doesn't follow from the first statement.

>the latter statement is false
Prove it, faggot. 0 (as opposed to 0.0 or 0.f) represents the integer 0 in C.

>I didn't say it and it doesn't follow from the first statement.
Either your first statement is a non-sequitur, or the second statement does follow from argument. There's no way around it.

You didn't use == in that expression, so it's invalid C. But now that you have explained your reasoning, and if it worked that way, I suppose it would make sense. Not sure what point you're trying to make here.

Multiplication and deference are not the same operator you moron.

where is my real life lain equivalent?

bumping this out of curiousity

Actually, better to say *i is a valid C expression whereas (*0=0 i) absolutely isn't. Also, (i*0==0) is still true even if i is a float, so I take that back, it doesn't make sense.

what does the * mean?
and why do i sometimes see things prefixed with &?

Why should I use a unit testing framework instead of writing a bunch of tests directly into my code?

>Not sure what point you're trying to make here.
The point is that your argument is not an argument. I could easily come up with something equally absurd that is valid C and effectively describes something fundamental about a type from which the type could be deduced. Clearly "it perfectly describes what happens" is irrelevant.

*p is the variable stored at address p.
&x is the address of the variable p.

You are literally subhuman. Please remind me why "people" like you have rights.

What about ->?

Does your language provide a way to disable said tests

I could just put them behind an ifdef in C, so yes.

>0 0*i;
0*i is a perfectly good C expression, and when you do this, you get the integer 0, so clearly this is an appropriate way to define a variable 'i' of type int, because it perfectly describes what happens.

x->y is shorthand for (*x).y

>one inane discussion followed by another

thanks

>I could easily come up with something equally absurd that is valid C and effectively describes something fundamental about a type from which the type could be deduced.
It would not be the best way to declare the variable, but it would not be WRONG, and it would not be better than how C does it. As long as you accept that then whatever. I don't even like C and I especially don't like how it expects you to declare pointers.

p->x = (*p).x

Under C's rules, 0 is also a float, so no, it's not correct to say that you can deduce i is an int from that. Unless you wish these "declaration expressions" to follow different rules from the rest of C.

0 is not a float, 0 implicitly converts to the float 0.0f.

It's the same thing. i*0 == 0 is true if i is a float.

>It's the same thing
Next thing you'll tell me that arrays are identical to pointers and that void foo(int arr[]); is a valid way to declare a function prototype.

They might as well be the same thing since you can't distinguish between them except in syntax. Why are all your arguments based on slippery slopes, anyways?

>it would not be better than how C does it
So you mean using syntax to "describe perfectly what happens" isn't generally better than a type descriptor followed by a name? Guess your "argument" was intended to be a non-sequitur, then?

>Under C's rules, 0 is also a float
If 0 was a float, multiplying by it would result in an implicit cast to float like multiplying by 0.f. That is clearly not the case because 0 is the integer 0.