Wikipedia:Reference desk/Archives/Computing/2016 February 2

Computing desk
< February 1 << Jan | February | Mar >> February 3 >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


February 2

edit

Mobile editing on Wikimedia projects

edit

When was mobile editing first enabled out of beta for anyone on any Wikimedia project using any method?—azuki (talk · contribs · email) 05:40, 2 February 2016 (UTC)[reply]

@Eat me, I'm an azuki: I do not understand the question. Mobile devices use extra CSS instructions to change the appearance of a website and optimize it for mobile devices, but other than that there is not much of a difference. Before en.m.wikipedia.org existed you could simply use the desktop version of the website on a mobile device. The Quixotic Potato (talk) 04:36, 3 February 2016 (UTC)[reply]
I was asking about editing enabled from en.m.wikipedia.org.—azuki (talk · contribs · email) 10:47, 3 February 2016 (UTC)[reply]
It was sometime just before this date [1]. Nil Einne (talk) 11:57, 3 February 2016 (UTC)[reply]
Yes,but how about through an official WMF app?—azuki (talk · contribs · email) 07:51, 4 February 2016 (UTC)[reply]
Don't know, you only asked about en.m.wikipedia.org or if we generous that you're overspecific maybe the mobile web sites in general. (Your first question is fairly unclear, since as mentioned mobile editing has been supported since browsers supported it. Probably Opera Mini or earlier.) Nil Einne (talk) 17:43, 4 February 2016 (UTC)[reply]
Possibly [2] ([3] [4]) although I can be certain a non beta status Android app wasn't released somewhere other than the Google Play Store before it was released on the Google Play Store. However considering it was still beta in a few weeks before, it can't have been that different. There is also an official wiktionary app and was an official commons app (now community maintained) and a semi official wikivoyage app, and I don't know when editing was enabled in these apps. The commons app supported uploading and adding categories from release so may have supported editing [5]. I'm presuming you're referring to official apps. If you're referring to unofficial apps, it's really difficult to know since the various APIs have supported editing for a long time and you could always just use the HTML interface plus not all developers clearly distinguish between beta or test releases plus there are so many different places where something could be released (and does it even have to be released, if I make an app for myself and call it non beta, this would seem to fit your first question). I mean considering as already mentioned you have been able to edit with the webinterface on mobiles since they had browsers that supported it, all you needed was an open source browser or a way to access the internal browser engine, you could then restrict you app so that you can't type in URLs and make it default to wikipedia (or whatever) and say you have a wikipedia app which can edit. Nil Einne (talk) 15:48, 5 February 2016 (UTC)[reply]

STL maps

edit

Hello. I'm using the STL in C++ and have an object of map class:

 map<vector<signed int>, double>

and I have realized that, in a given map object, all the vector objects are guaranteed to be the same size as each other. I know the size at runtime but not at compile time. In my application, quick running time is paramount. Is there any way to "use" the fact that all the vector objects have the same size? Robinh (talk) 20:17, 2 February 2016 (UTC)[reply]

You might be able to use std::array instead of vector, but measure your program's performance with each before committing. std::array is a C++11 feature, so no good to you if you are stuck with an earlier standard.-gadfium 20:28, 2 February 2016 (UTC)[reply]
Sorry, I missed that you don't know the size at compile time. std::dynarray is the version you might want, but that's a C++14 feature. I think most current compilers will support it.-gadfium 20:35, 2 February 2016 (UTC)[reply]
thanks for this! This seems to be what I'm looking for. I've modified my code but it won't compile, I presume because I have an old version of C++. Can I verify that a dynarray can be used as a key in a map? I am getting confused as to what can and cannot be used as a key. thanks again, Robinh (talk) 20:44, 2 February 2016 (UTC)[reply]
I'm not sure that dynarray is in C++14. I see various reports on the net that it was rejected, and the C++14 article doesn't mention it. It would probably have no advantage over vector except saving one machine word per key (vector typically uses three words for the heap pointer, size, and capacity, but dynarray doesn't need to store a capacity).
If you don't need map's key ordering guarantee, try using unordered_map instead. It will probably be significantly faster.
If the fixed array size will often be small, you could make a template class that takes the size as a compile-time parameter and uses array keys, and a wrapper with a switch-case statement that uses instantiations of the template class for certain sizes and a fallback implementation for other sizes. If you're lucky the compiler will unroll and vectorize the loops in the template code and significantly improve the speed. -- BenRG (talk) 22:24, 2 February 2016 (UTC)[reply]
(OP) yes, unordered_map is *exactly* what I am looking for! I don't need the keys to be ordered. I was a little taken aback to discover that unordered_map allows one to iterate from start to end. My problem now is that I get an "implicit instantiation of undefined template" error, which I simply do not understand (it compiled before, and the only change I have made is to replace "map" with "unordered_ma"). But stackoverflow (which is usually excellent for this sort of thing) isn't helping. Any advice? Robinh (talk) 23:00, 2 February 2016 (UTC)[reply]
Avoid template metaprogramming entirely? Sorry, but you asked for advice...
In total seriousness, we need a larger code snippet before we can evaluate where you went awry, at least with any specificity. "Something somewhere" is illegal syntax, and your compiler is telling you so.
If the exactly only change you made was to replace std::map with std::unordered_map, you should know that these templates have different signatures: unordered_map needs a predicate comparator for equal_to.
Nimur (talk) 23:58, 2 February 2016 (UTC)[reply]
Consider:
#include <map>
#include <unordered_map>
#include <vector>
using namespace std;

map<vector<signed int>, double> my_map;
unordered_map<vector<signed int>, double, std::equal_to<vector<signed int> > > my_unordered_map;


int main(int argc, char** argv)
{
  return 0;
}
... which did successfully compile using my system's c++ compiler, clang.
If neither std::equal_to nor any of its standard alternatives will do what you need or expect... or if its performance does not meet your expectations... you must implement your own binary predicate.
Isn't template programming great? It really makes you totally unable to know whether your efficient optimization will actually run efficiently... Nimur (talk) 01:09, 3 February 2016 (UTC)[reply]
You don't need to specify any extra template arguments to unordered_map. The third argument, if you do specify it, is a hasher, not an equality predicate. Your code probably compiled because you never added anything to the unordered_map, so the ill-typed hasher was never used. -- BenRG (talk) 08:08, 3 February 2016 (UTC)[reply]
Your point is accurate; I shoved the equality operator into the hash function. I could have written better, more completely-defined code by explicitly providing all arguments to all the templates. To be fair, I just made sure the code compiles - not verified that it "works in any specific way." Our OP's original trouble was an error instantiating the template, which is fixed in my listing. The template is instantiatable, but it may behave incorrectly, depending on what you expected it to do.
Maybe I'll write out a more complete listing later as a working example; or perhaps you'd like to provide some code.
Nimur (talk) 17:00, 3 February 2016 (UTC)[reply]
Template classes are not fully instantiated just by declaring a variable of that type. Only if you actually use a method will it be instantiated and type checked. Because you never inserted anything into the unordered_map, none of the associated code was type checked. equal_to<T>() takes two arguments while hash<T>() takes one, so it would have failed the type check. You didn't fix anything.
I linked to working code in my post. -- BenRG (talk) 03:01, 4 February 2016 (UTC)[reply]
I think the problem is that there's no built-in definition of hash<vector<int>>. Since performance is important, you should pick a high-performance hash function like SipHash or xxHash and then specialize std::hash or use a third template parameter as shown here. -- BenRG (talk) 08:04, 3 February 2016 (UTC)[reply]
(OP) OK thanks, I'm beginning to understand. But how come std::map doesn't need a third template parameter if, as you say, there is no built-in definition of hash<vector<int>>? Robinh (talk) 08:39, 3 February 2016 (UTC)[reply]
That is not accurate; the default implementation depends on your implementation (tautologically!) but nearly all implementations use the object-pointer as the key into the hash (often in tandem with an equality check, which is why the template to produce the operator == is an important argument to the template). I think you are led astray again.
For details of LLVM's implementation, see the Programmer's manual entries on std::map and other map-like templates. You will also see that even the compiler programmer manual remarks about the "unique" difficulties of performance when using these sets - so I am in good company when I take a jab at the performance impact! The folks who wrote the LLVM manual even put a smiley-face as they remind you: "As usual, there are a lot of different ways to do this. :)" ....That's your clue that you're about to find the compiler doing something awful and incomprehensible!
Nimur (talk) 16:35, 3 February 2016 (UTC)[reply]
Nimur, you clearly don't understand C++ or the STL. I don't understand why you are responding to this question at all. Nothing that you've said makes any sense. std::map is not a hash table, but an autobalanced binary tree (usually red-black), and does not use a hash function at all. I can't make any sense of the stuff about "using the object-pointer as the key into the hash". Are you talking about some other hash table implementation in some other language? In any case, what I posted is correct; everything that you've written is clutter that I or someone else have to clean up after, because you have no idea what you're talking about. -- BenRG (talk) 03:01, 4 February 2016 (UTC)[reply]
User:BenRG: sure, we can make an agreement that you can handle all the C++ template questions that show up at WP:RDC in the future. I sincerely apologize if there were actual errors in anything I linked or wrote, although there's no need for you to be incivil if you ever find some mistake in my work. In any case, I've lost track of this thread, as I have been on vacation since Wednesday (at sea, watching the annual gray whale migration, and remarkably without any network access). In my absence, it looks like you've got this C++ issue totally under control. Thank you for your efforts and for contributing your expertise in C++. I'll stick to the pure C/sea stuff. Nimur (talk) 16:40, 7 February 2016 (UTC)[reply]