If your argument is "These algorithms have differing degrees of computational complexity" then that doesn't actually demonstrate that one can't be algorithmically determined
Describe the n-th digit of an irrational number without calculating all previous positions of the number.
If pi were a sequence of digits, there is no algorithm to calculate it other than by calculating pi but there is one for op's number. The very fact that he could show the algorithm for creating the sequence of numbers in his post is indicative of that.
For pi such an algorithm doesn't exist (other than calculating pi itself).
I wanted to emphasize this by talking about the "sequence of digits" in my original reply but apparently I failed at explaining this well.
I can't really tell to what extent you're not computing previous digits (or doing work that could quickly be used to come up with these previous digits) with this algorithm but O(n^2) seems quite heavy compared to
O(1) (I expect) to get the n'th digit of op's number.
Maybe I should rephrase it:
My assumption is: If there is an O(1) algorithm to determine the n-th digit of an irrational number x then the number is still "of a different class" than the likes of pi and there OP might not be able to induce things from this "lesser class of irrational numbers"
Location: Heart of Europe
Remote: Yes
Relocate: Depends
Data scientist/engineer working in a neat and well-paid position is looking for a new challenge, preferably dealing with functional programming and in a quant/trading related domain.
I bring low-ego / social skills, well-rounded technical knowledge and an analytical mind.
chuhujitri@matra.top (email is throwaway and randomly generated)
A fried of mine reported scientific misconduct (p-hacking) and, together with a few colleagues, left the research group, due to moral harassment by the head of that group.
The university removed all of them from the research group and said they could continue working on the data because it belongs to the university.
3 months later:
- investigations of scientific fraud against the people leaving (neglecting authorship because the data could after all not be used and the head wanted a say in the articles, i.e., change them completely). Also some random other allegations that didn't stick.
- police investigation of defamation (because they reported the scientific misconduct and some other misleading statements used by the head in sales for a research-related product)
- the university now expects them to contact the head of the ex-research group to clarify questions of authorship
Requirements: Be smart, love to learn, be comfortable with working remote and know a few of the following (in order of decreasing priority): clojure, cljs, js, SQL DBs, git, java, Statistics, Machine Learning, NoSQL DBs, Continuous Integration, Admin, Devops
I have a number of data science projects, personal and business, where I would need a helping hand. Typically I do them myself (full stack) but recently I find myself doing more acquisition and results presentations, so help somewhere along these lines is appreciated.
I would start with a small project, via upwork if you prefer, and go from there.
Frankly, I don't see how regulations or laws should protect the user for several reasons:
Firstly, there are already privacy laws yet it doesn't look as if they apply and that Verizon thinks that even in the case of a law suit Verizon will be able to benefit more than this law suit will cost.
Secondly, even if a court determines that the conduct of Verizon in this case is not legal, the verdict will still be special enough to not be applicable in a loop hole case. So I see protection provided by law as limited.
Thirdly, enforcement is rather difficult and not as obvious as, e.g., a daylight robbery, especially for non-technical observers which I presume to be the vast majority of law enforcement personnel.
And finally, (and rather an opinion) I think government is rather delighted to know who does what on the internet, so I don't see a real motive for them to move decisively apart from some half-* voter appeasement.
I think he means that _using clojure_ (to implement the IDE) is very language specific as opposed to saying "it is based on clojure" or "clojure is cool because X" (which everyone can).
I believe they are talking about the programming experience vs. the implementation. Here is the specific passage:
> Additionally, Clojure's strong view on how state is managed, the distinction between identities and values and the focus on immutability all make it easier to deal with the complexities that come with "live programming".
The first point makes sense; the second point doesn't. Immutability either avoids the problem of change by denying or pushes it up for someone else to handle. So say you have a dictionary: do you handle change directly by mutating the dictionary or do you create a new dictionary to be diffed later? The first way is much easier than the second.
The next sentence is true:
> Having a strong concept of what state is and how state transitions occur makes programming tools simpler.
This is very true, but again detecting a state transition is much easier when you allow for mutation of state (otherwise, diffing must be used, and that's expensive).
But anyways, this isn't really live programming as envisioned by Hancock: there is a manual "re-evaluate this line code" command under the current program state; there is no repairing of the past; compare against the Elm live programming demo, which is fully live at the code level.
To be fair to Clojure, it has a much more nuanced approach to state management than simple encouraging immutability. It pushes that you should be immutable whenever possible, but if you must use state then you should use it in a controlled and understandable way either by atomic operations, transactional memory, or agent. Further, it provides implementations of all of these things.
So Clojure explicitly allows for state transition and provides controlled and standardized ways of handling it. One of the selling points of Clojure is that it speaks to practicality in implementation by providing alternatives, or in the extreme case, complete escape hatches to low level tools that avoid even it's state control mechanisms. It simply encourages first immutability, and second state control in a well defined way.
I agree with this; Clojure's design is incredibly pragmatic about state, including mutable state, like any good Lisp.
People just tend to misinterpret this, or they digest it as "immutability good for live programming" when that isn't true: immutability is great for programming with values, but please don't make an immutable world object and replace it when something changes! Unless you are using Javascript, I guess there is just no other way to deal with the DOM other than diffing.
Panic is actually more well known as a company that makes Mac apps. Many would call them the preeminent developers for the Mac platform (along with Omni). So think of it like this...
A hugely popular (for its market), established, independent, and profitable software company gives clear and transparent insight into how the past year has gone for them and their products.
Panic is one of the best-known Mac-only software developing companies that are out there, well connected in the blogosphere, been around for quite some time and their products generally loved by their users.
It is a matter of opinion if that makes them special or not.
I guess their Panic report hasn't been upvoted just for being from Panic but also because we have here another critical voice of Apple and the Appstore processes from a company that for sure doesn't just like doing Apple-bashing.
Panic are one of the longest standing developers of Mac Apps. They used to make one of the earliest Mac MP3 playing apps (called Audion) which very nearly got purchased by Apple as the foundation for iTunes.
Not really, which is why their report is interesting. I don't run a software company, so it's interesting to see the report from a company whose software I use. Plus their posts tend to be well-written.
Compare to patio11, who runs a couple of small online services that together gross only a couple hundred thousand dollars per year--nothing remarkable, from a business sense. Yet his blog posts about running a software business regularly shoot to the top of HN because they're well-written posts about running a solo software business.
I work 50%+ in Clojure as an IT Consultant and here in Europe it's not that easy to find a company that uses Clojure and embraces its benefits.
When I use clojure, it's typically for companies who need to get something done and then I choose clojure to do it, but only once someone specifically asked me for clojure (but it was an American company).
I don't find it as easy to work as clojure guy in Europe.
In comparison, in the US there's much more demand but many companies refrain from remote contracting Europeans (even though I think my background is quite good ML, Data Science, Statistics, ..)
So IMO the TL;DR is: filling clojure positions is only a problem in the US, not in Europe.
I wrote exactly these two tags "fast thinker" / "quick learner" in my CV / cover letter / LinkedIn profile and I removed them a few months later because from my experience it looks like they drive recruiters away or scare them.
I can only speak for myself but terms like that set off my BS meter and probably make me think at least marginally less of whoever sticks them on their resume. They're vague and unquantifiable. They're of a class with words like acclaimed, industry-leading, and so forth in copy describing products.
Yes, for that reason I took it off, still the question is how can one communicate that one is? Should you write "constantly programmed faster and leaner and with less errors that his colleagues?". I don't think there is a way to communicate this but I still think it matters.
You can easily determine if some one is a BS guy in a technical interview anyway, so I don't think, BSers are very frequent in IT and much less so in programming.
Results, achievements, accomplishments. Frankly I don't really care if you were better than the guy in the next cube. He might be an idiot or a complete slacker.
And I'm not sure I wouldn't get negative vibes from someone who felt they had to position themselves by de-positioning the people they worked with.
>You can easily determine if some one is a BS guy in a technical interview anyway, so I don't think, BSers are very frequent in IT and much less so in programming.
For your example there is an algorithm to describe the sequence of digits and for Pi there isn't.
EDIT + Clarification: There is an algorithm to calculate the digits of your number without calculating all previous digits. But for pi there isn't.