/dpt/ - Daily Programming Thread

can someone post more of the pro/g/ramming challenges or projects? or other things to do? i need more stuff to do

solve the halting problem

How do I achieve this
(let ((counter 0))
(defun reset () (setf counter 0))
(defun get-count () counter)
(defun increase () (incf counter)))

in Scheme, but without having to set! some global definition to a lambda created within the let?
i.e. not this
(define reset)
(define get-count)
(define increase)

(let ((counter 0))
(set! reset (lambda () (set! counter 0)))
(set! get-count (lambda () counter))
(set! increase (lambda () (set! counter (+ counter 1)))))

Surely there must be a hack around this, a macro maybe?

Ok, I have a map with a vector pair inside it declared like this

typedef vector vectorPair;
map map;

How would I access the pair inside the vector with an iterator? I've been googling every and can't find shit and feel like a moron.

int willhalt(void (*func)(void *), void *input) {
return 1;
// FACT: all functions halt no matter what
}

Is Qt a worthwhile skill to know if I'm trying to get a job doing C++ programming? If not, what frameworks/libraries would you recommend I learn to get a job doing C/C++? No microcontroller shit, I'm trying to get away from that and "move up the stack" so to speak.

for (auto it=v.begin() ; it!=v.end();++it)
{
std::cout

Check out stackoverflow.com/questions/39066621/let-over-lambda-in-scheme

That would work if this were just a map that contained a pair, but it's not, which is why I asked because any combination of "how to access map values contained within vector pair" has hardly brought up anything.

auto it = map["key"].begin();
auto x = *(it).first; // gets the first element of the first pair
auto y = *(it).second; // gets the second element of the first pair

well, you have to combine the concepts you already know. if you know how to access map values via a map iterator, and you know how to access vector elements via a vector iterator, and you know how to access the elements of a pair, then you already have all the knowledge you need to figure out for yourself how to access the elements of pairs that are elements of vectors, via iterators into those vectors, when the vectors are elements of a map and are being accessed via an iterator into that map. try thinking for yourself instead of immediately turning to /dpt/

>band
wat

void doesnthalt() {
while (true) {}
}

Thank you.

My next question is about macros.
How do I just use Common Lisp's defmacro instead of define-syntax?

No idea, they didn't have this last cppcon, and it's pretty annoying.

when you die and stop paying the power bill the computer will be forced to shut off

"you", "power bill" and "computer" were not arguments to this function.

>try thinking for yourself instead of immediately turning to /dpt/

I turned to /dpt/ because I've been trying to put all that together for the past few hours now, but whatever, sorry for asking if someone knew something I didn't after trying to find the answer myself.

You don't get it. The code I wrote is to iterate over your vector or pair. And it just has to be wrapped in another for loop doing the same find for each key of your map

en.wikibooks.org/wiki/Scheme_Programming/Macros

Do you know how to get an iterator from a map and use it to access the mapped values of that map?

Do you know how to get an iterator from a vector and use it to access the elements of the vector?

Do you know how to access the elements of a pair?

If you know all three of these things, then no, no one here knows something you don't (about this particular problem, that is) because there's nothing TO know that you don't.

Frankly I'm curious where you're getting stuck. What kind of mental trouble are you having putting these concepts together? What is it exactly that's striking you as not seeming to fit?

>Frankly I'm curious where you're getting stuck.
I literally just told you.

Just so you would be done with this, here is the code doing what you want :

typedef vector vectorPair;
map mymap;
For(itMap = mymap.begin();itMap!=mymap.end();++itMap)
{
//iterating for each member of your map
For(itPairs = itMap->second.begin();itPairs!=itMap->second.end();++itPairs)
{
//iterating for each element of one vector of your map
String s = itPairs->first;
Int i = itPairs->second;
}
}
Good night

And put the auto before declaring itMap and itPairs

Attached: ebh6fhxkn0911.jpg (1242x1329, 257K)

Thank you!
Does scheme have reader macros?

they're added in by the hardware implementation

No, you didn't. You told me that you've been trying to figure it out yourself for the past few hours. I'm asking for greater detail than that. I'm asking you to walk me through your process. I'm having difficulty imagining someone, intelligent enough to comprehend in the first place what vectors, maps, and iterators even are, not being able to follow the following reasoning:
>i have a map
>for any K and T, i know the algorithm i can use, let's call it X, to get a map::iterator from a map and use it to get T's out of the map
>for any T, i know the algorithm i can use, let's call it Y, to get a vector::iterator from a vector and use it to get T's out of the vector
>for any A and B, i know the algorithm i can use, let's call it Z, to get an A or a B out of a pair
>therefore, to get an A or a B out of my map, obviously i have to do X, do Y within each iteration of X, and do Z within each iteration of Y
What's going wrong here? What barrier, specifically, is preventing you from being able to do this?

The halting problem doesn't care about your hardware.

Kind of. srfi.schemers.org/srfi-10/srfi-10.html
If you need CL features, use CL.

>I have X
>How would I access the pair inside the vector with an iterator?
"No, you didn't."

I'd ask why you're having such a hard time understanding a simple question, but I don't post here to be a condescending shit towards people who aren't afraid to admit they don't know something.

Yeah it does.
You told the other guy (who wasn't me btw, i was the person you originally responded to with doesnthalt) that:
>"you", "power bill" and "computer" were not arguments to this function.
I strongly disagree.
They weren't arguments to the subroutine. They are, however, absolutely arguments to the function, in a formal sense transcending language details. Just like what winds up going on at the hardware level is merely one implementation of the language, the language itself is merely one implementation of the overarching concepts of what constitutes an algorithm or a function, and guess what? The halting problem doesn't care about your programming language either. The fact of the matter, is that no matter what your language says, all details which may affect the operation of a function ARE formal arguments to the function. Just not on the computer.

damn that's an old ass /f/ meme

The halting problem doesn't say "Does this function halt under implementation X", it says "Does this function halt".
There is no reason why we can't make an implementation that never stops. Perhaps it outlives the death of the universe somehow by being transferred into another universe.
What now faggot?

I was under the impression that you knew how to access vector elements with an iterator.

I now understand the problem: you know how to access mapped values of a map with an iterator, and how to access the elements of a pair, but you DON'T know how to access VECTOR elements with an iterator. Is this accurate? Because if so, you should've said so in the first place, and this entire conversation could've been avoided.
>inb4 i did say so
You didn't. You said you didn't know how to use an iterator to access PAIR elements of a vector IN A MAP. That's needlessly specific and merely confuses matters. It's important to be able to point out specifically which part of that process you don't know how to do. Thank you for finally doing so.

Anyway, here's how you access elements of a vector using an iterator:

vector vec = {/* whatever */};
for (auto iter = vec.begin(); i != vec.end(); ++i) {
T &element = *iter;
// you can just dereference the iterator
// as if it were a pointer
}

Making utilities for my organization.

>There is no reason why we can't make an implementation that never stops.
There is indeed a formal and abstract such reason that's fully implementation independent. It's called the laws of thermodynamics

I feel like Scheme is simpler and will produce smaller binaries.

>science zealots actually believe this

Maybe. You could use ECL too.

What makes you think computer science cares about thermodynamics?
What makes you think we can never overcome it? Just because we can't now doesn't mean we can't later.
Perhaps we find a way to transfer between universes and create/destroy energy.
Whatever, doesn't fucking matter. The implementation doesn't matter because there's no reason there can't be a theoretical implementation that never stops. So your argument is stupid.

>this entire conversation could've been avoided
I think this entire conversation could've been avoided if you actually knew how to talk to people, but I'm the beggar, and this is Jow Forums, after all.

But thanks anyway.

if you're already using the auto feature from c++11, why aren't you using the new for-iterator syntax?

for(auto& t: vec) ...

Lisp is brilliant and useful, but it's not the be all end all of programming.

>he isn't a science zealot
>he either doesn't believe in science, or believes in science but not enough to trust it to an extent which might be described as zealous
>he is unwilling to place his full trust in the repeatable and time-tested consistent outcomes of literal centuries of experimentation
>he is unwilling to place his full trust in observations which have been successfully reaffirmed for an amount of history several times his own lifetime in length
>and yet he is most likely willing to place his full trust in facts that HE PERSONALLY observes on a consistent basis, such as that he is here and alive, the sun is too bright to comfortably stare at, and the sky is blue in the daytime in fair weather
>ergo, he places greater trust in facts which he only knows to have been observed by one person, himself, and only for the duration of his life on earth so far, than he's willing to place in facts which have been consistently observed by swarms of people for multiple fucking centuries
>his priorities are this backward
>he is this retarded

Attached: 1511878352681.gif (500x464, 81K)

Daily reminder ...

if (massiveTits && !hasACock()) {
auto jizz = blowLoadOnTits();
} else {
gas();
}

>science zealots actually believe this shit

>t. brainlet

I'm not here to just give away answers, I'm here to make sure you actually think these things through and make a real effort to put together the things you know. Until you revealed the crucial piece of information that you didn't know how to extract values from a vector using an iterator IN GENERAL, and not just in that specific case, it really, REALLY didn't sound like you'd made any attempt whatsoever to puzzle through it with what you already knew. Before I understood, that disgusted me, and I was determined to rectify it as best I could. No one should ever program without fully understanding what they're doing -- unless they're on the path to that understanding, that is, and not just content to stagnate in the dark ages of copy-paste.

>he thinks that anything i just said has anything to do with believing and is not a pure and simple beatdown based solely on logic and semantics
>his reading comprehension is this poor and/or he didn't even read it
>he is this retarded

Attached: 1535362346239.gif (297x268, 600K)

#include

int main(){
printf("Hello, world!.\n");
}

When I was a teenager I was almost as fucking retarded as you
I grew out of it, but from the sounds of it you grew into it.

>he doesn't even have a counterargument
>he actually believes this means he has won
>he is this retarded

Attached: 1518549385681.gif (960x720, 255K)

I don't think he was trying to win.

>there's no reason there can't be a theoretical implementation that never stops
There is, because the laws of thermodynamics are theoretical limitations, not just practical.

*finds way to pull in energy from other universes, of which there are infinite of*
What now faggot?

>*finds way to pull in energy from other universes, of which there are infinite of*
No you didn't, because that is not possible.

>he doesn't even have a counterargument
I am trying to help you. You are making a serious mistake. When I was a few years younger, I would have acted just like you are acting now. The first step is for you to stop and listen.

How do you know?
You have no idea what's in store for the future. We're talking billions of years of scientific advancement here.

In his 1970 address on "The meaning of
beauty in the exact sciences," Werner
Heisenberg, who formulated the uncertainty
principle, put the matter thus: "If we look
back on the history of the exact sciences,
it can perhaps be asserted that the correct
representation of natural phenomena has
evolved from this very tension between the
two opposing views. Pure mathematical
speculation becomes unfruitful because from
playing with the wealth of possible forms it
no longer finds its way back to the small
number of forms according to which nature is
actually constructed. And pure empiricism
becomes unfruitful because it eventually
bogs down in endless tabulation without
inner connection. Only from the tension,
the interplay between the wealth of facts
and the mathematical forms that may possibly
be appropriate to them, can decisive
advances spring." [25]

...

The physicist appeals to a reality outside
his mathematics to discover the very few
systems that have any chance of being
significant. This is because he has the
gift of language to create, among an
infinite variety of mathematical systems,
more plausible systems than he can possibly
evaluate. He has confidence that his
central principles are sound if they hold
unchanged at boundaries. Such extensive
validity is so unlikely that he has faith
that his principles reflect "the small
number of forms according to which nature is
actually constructed." [25]

The Nested Rectangular Array as a Model of Data

I'm listening. I've been listening this entire time. I've found there's been nothing of interest here to listen to. Just the same boring, tired idea that the halting problem is unsolvable, which demonstrates blatant ignorance of the inevitability of entropy.

You're listening only for what you want to hear.

From trying to acclimate to your perspective, the information I would be looking for is when a program halts at the end of the universe or when it halts before that. I don't really care whether or not you call that the halting problem.

Well, there can't be infinitely many universes, for one thing. And for another, if you could draw in infinite energy, you'd be perpetually increasing the mass of our own universe, which would eventually cause it to collapse. So that doesn't really change anything.

Well, sure, THAT problem's unsolvable.

>there can't be infinitely many universes
What the fuck do you know?
>if you could draw in infinite energy
Transfer the same amount out later. Who cares about the surrounding universes.

>What the fuck do you know?
That quantization effectively forbids infinities.
>Transfer the same amount out later. Who cares about the surrounding universes.
We will, once they collapse. Imagine the gravitational pull of a black hole with the mass of a universe.

>That quantization effectively forbids infinities.
The integers are quantized and they're infinite.
Also, who says the universe is quantized?

>Imagine the gravitational pull of a black hole with the mass of a universe.
Universal-black-hole-powered computer.

>>Transfer the same amount out later. Who cares about the surrounding universes.
Also, your "later" supposes that either A) we'll be able to transfer out energy which has been used and is no longer useful (which we can't, because that energy is by definition lost from the system and inaccessible by any means that would not consume and re-lose the very energy it means to manipulate) or B) there IS a "later" at which time energy REMAINING IN THE SYSTEM is no longer useful, which is equivalent to the assumption that the program terminates.

>actual retard doesn't understand undecidability
LMFAO am I even surprised? These are the kinds of """people""" giving your programming """advice""" here.

Attached: smug_ran5.png (529x735, 325K)

>The integers are quantized and they're infinite.
>Also, who says the universe is quantized?
We're not talking about just any kind of quantization here. We're talking about the now-known quantized nature of space, time, energy, mass, and information.

>Universal-black-hole-powered computer.
Would be destroyed by its power source.

That's what happens when /sci/tards try to get into programming.

>Would be destroyed by its power source.
Make a universal-blackhole-powered computer that doesn't get destroyed by it's own power source. Done.
What now faggot?

>part of CS theory with firm group theoretic foundation
>"programming"
I agree Dunning-Kruger-ridden freshmen from /sci/ can be almost as retarded as you lot here but all you're doing is embarrassing yourself.

Attached: smug_ran6.jpg (802x1240, 114K)

It's not undecidable if you take into account the scientific fact that all programs that do not halt as a natural consequence of execution will invariably halt as a consequence of outside influence. I do not deny, and have never denied, that the halting problem is certainly undecidable in a system that excludes this fact.

>w-watch me change the definition of the word in order to fit my narrative
Not how the world works, champ. The definition of "halting" literally makes no reference to the real world.

Attached: smug_ran9.jpg (1040x1452, 781K)

>Make a universal-blackhole-powered computer that doesn't get destroyed by it's own power source.
That power source will still run out. Black holes give off radiation, and eventually disappear by exactly that means.

It doesn't have to make a reference to the real world, the fact that any process whatsoever necessarily has to come to an end can be represented in pure math.

How the FUCK do I assign int variables to the numbers in a string with Java
I’m losing my MIND

Say I have a number like 123-456
HOW DO I fucking say “int a = string[0]”

I’ve tried converting to arrays, parsing, charAt, etc.
Please help. I may be a brainlet but also I cannot find anywhere on the internet with answers. Especially because throwing a dash in makes everyone retarded apparently

Attached: 483E342F-95B3-4478-BED3-5765E6B0B50F.jpg (599x555, 50K)

Basically int a = string[0] = value of 1

Split the string on the dashes.
Integer.parseInt the elements of the split.

Make a time machine to turn back time to point of creation of black hole, and come up with a way to transfer the current program and machine state through the time leap and replace the old state. Done.
What now faggot?

>It doesn't have to make a reference to the real world
Literally every single argument you've made in this thread have.
>the fact that any process whatsoever necessarily has to come to an end can be represented in pure math
Do it. I'll wait.
Also I like how you stopped using the word "halt". By switching to ambiguous natural language you can goalshift however you want.

Attached: smug_ran2.png (1000x1000, 495K)

Oh. Never mind what I just said.
New plan.
Split the string on the dashes.
Convert each element of the split to a char array.
Convert each char in each array to a single-char string.
Integer.parseInt each single-char string.

THE ONLY ANSWER!

Does java really not have a "take"?
auto str = "123-456";
int a = to!int(str.take(1));

>Do it. I'll wait.
No.
It can be done. That's all I need to say. You know perfectly well it's true, and it needs no proof.
>Also I like how you stopped using the word "halt".
Literally doesn't matter. If a process comes to an end, it halts. Same thing. A better formulation of the halting problem, more demonstrative of true undecidability, would be to find an algorithm to decide if any given algorithm will eventually halt of its own accord.
Lol.
Relativity forbids this

>Relativity forbids this
One day relativity gets proven false or we find a way to work around it.
What now faggot?

>it needs no proof.
>Literally doesn't matter.
Giving up already I see. All that bullshit word salad and namedropping can only get you so far, huh kid?
Do the world a favor and neck yourself.

Attached: smug_ran.jpg (709x1063, 632K)

I dunno, pretty sure you could use a substring method to accomplish the same functionality you're demonstrating here. But regardless, I do know that your algorithm is incorrect, translated to Java or otherwise. It fails to account for the dash. You need to split on the dash and rejoin. Or better yet, split on /[^0-9]/ and rejoin. After the split and rejoin, your algorithm would work

This took me longer than i'd like to admit
Given two binary trees and imagine that when you put one of them to cover the other,
some nodes of the two trees are overlapped while the others are not.

You need to merge them into a new binary tree.
The merge rule is that if two nodes overlap, then sum node values up as the new value of the merged node.
Otherwise, the NOT null node will be used as the node of new tree.