Alright @GuineaPig I'm out, I will try to take a look tomorrow, if any pro has any idea in the mean time let me know :) Thanks @acl for testhing the code :)
@RolfMertig By all means. Send Wolfram Technical Support these examples. They're simple and concrete. The sooner issues like this are reported, the more likely we can get any fixes for any issues they reveal into the next build.
Many people when they see something like this will send huge notebooks which require a considerable amount of effort to analyze and demand very concrete explanations. Tech support is probably very busy because of the release, so they may not be able to offer an explanation, but will make sure the appropriate person looks into it.
Since MapThread accepts a level specification, I think our ragged MapThread function should too.
raggedMapThread[f_, expr_, level_Integer: 1] :=
Apply[f, Flatten[expr, List /@ Range[2, level + 1]], {level}]
To solve the specific case posed in the question:
raggedMapThread[
Count[{##}, 0] &
Any suggestions for how I might modify that answer to make it more interesting? Am I mistaken in thinking that this is a useful function?
It's not about the votes here; rather I put some effort into this function and I think it could be useful to a lot of people yet I don't think many people have seen it.
(Another thing coming, but W Community takes half a minute to load here!)
@halirutan Can you look at the last message here? I didn't reply yet.
And finally, a question to everyone in the room. How would you check that the diagonal of a matrix is all zeros, in a fast and elegant way? I have Union@Normal@Diagonal[mat] == {0.}.
@halirutan I just got 22:26:06 Throwable: Empty PSI elements should not be passed to createDescriptor. Start: PsiErrorElement:Closing ']' expected, end: PsiErrorElement:Closing ']' expected. Do you ever get these?
Objects are represented as Foo[id] where id as an integer. Then people would do foo = Foo[1] or something like that (actually, foo = MakeFoo[]). This part is fixed.
The objects have some properties. Some properties are mutable. There are also "methods" that can be called on the object.
I'm trying to figure out how to present all these possibilities to the user. If this is going to be user-friendly, I have to avoid potential surprises. Mutability can always be a surprise in Mathematica, so I'm trying to figure out a way how to make it very clear what operations mutate the object and which don't.
Right now I have this:
foo["SomeProperty"] will return a property.
ObjSetProperty[foo, "SomeProperty", value] will set that property. This is much more wordy, so I don't like it much, but it works.
There are also methods which can be called as foo["SomeMethod"][param1, param2]. This has two problems:
1. it's not so obvious that this can mutate the object
2. doing this prevents me from doing error checking on property names without too much fuss. I can't just do a generic definition like Foo[id_][s_String] := Message[Foo::nosuchproperty, s] because foo["SomeMethod"] would immediately evaluate trigger the error (that's because Foo[...]["SomeMethod"] has no assigned definition, only Foo[...]["SomeMethod"][...] has)
@rm-rf I actually have objects of the form Foo[1], Foo[2], etc. Then these are assigned to variables, e.g. foo = Foo[1]. That integer is just a handle to a data structure implemented in C.
@rm-rf Set has the property that if f=g and f[1]=2 then it assigns a DownValue to g, not to f. But it turns out that after Set evaluates f to g here, there's no more pattern matching done, so any special properties of g won't take effect.
:16628577 No. foo is just a variable holding Foo[1].
@rm-rf Interesting idea! It made me think of this:
Use the syntax foo["Property" = newValue] to set new properties? Instead of foo["Property"] = newValue. Ah, that's not possible because we can't hold in subvalue-definitions ... but maybe foo["Property" -> newValue]? Or does that look too confusing?
I have tested it now for several days and I still like it. I needed it for analysis results, where each each analysis is a biomedical object which has properties. In short, I use the following syntax:
prop[Open] (* read file from disc *)
prop[Write] (* write but don't overwrite *)
prop[Overwrite]
prop[Properties] (*return all properties *)
prop["key"] (* return the property for key or Missing *)
prop["key"->value] (*set a new property *)
prop[{"key1"->value1, ...}] (*set several properties*)
@Szabolcs With the new associations, overwriting properties (which is often what you want) is even easier... just add the new key->value to the existing one. Before, I'd filter rules, remove and then readd
@Szabolcs Yes. Best case scenario, "key"->val is natural for changing a property like associations, but if you wanted to be explicit about that op being mutable, it doesn look like it to me
@Szabolcs Ok, let's sit on it for now and let both mathlink and wstp evolve organically... we can merge and make one or the other master in a year or so. It is much much easier to synonymize, merge and make one the master than to do it hastily and then have to split it.
There was a question and someone edited it to add code blocks (it had none). I clicked on edit to add blocks myself, was presented with an interface to "approve" the edits, and approved them. Now it needs approval from one more user.
All I wanted to do was add the code blocks myself, but apparently I can't, all I can do is vote to approve someone's edits. Is this right?
I have been trying to see why this integration is not converging but to no avail. The output gives only the y-values but fail to give any real value for x-values. Rather I always have something like this: "0.1,-1,Re[NIntegrate[Abs[x + y - 1]^k*Sign[x + y - 1]*f[x, y, [Theta], [Rho]], {x, 0, 1}, {...
Sometimes I check how many users of mathematica.stackexchange.com there are.
I remember that a few weeks ago there were about 15 thousand and recently I've been surprised seeing that the new users are signed with numbers over 18000.
Let's check this site, the new users therein have numbers sligh...
I don't quite understand the logic behind the votes in the review queue. What bothers me is the following: I have enough reputation to do whatever edit I like without any approval.
On the other hand, if some low-reputation user makes an edit it comes in the review queue where a single vote of me ...
@Rojo well, let me start on this tonight then. I need to first read up on how to change stylesheets etc (I did find out once upon a time, but forgot again)
I load my mma with a custom user base dir. If I load it with the default one, it works (but it issues a message of a FailedQ shadowing conflict between System and GeneralUtilities)
@TaliesinBeynon It must be someting inside the user base directory. I don'tunderstand paclets at all, but I would have expected all the default functionalit to be independent of the user base dir
However, changing the MATHEMATICA_USERBASE env variable to my old windows user base dir is making this difference
I am checking what exactly is to blame inside that folder
@Rojo basically, if you look at the raw PacletInfo.m files under SystemFiles/Components/* you'll see Symbols -> {sym1, sym2, ...}. The paclet manager uses this to populate autoload stubs on the actual System` symbols so that mentioning them will autoload the paclet
ok, so here's what you can try: run RebuildPacletData[] with abandon and see if it fixes anything
@Rojo: thanks! lots of work still to do, which is why we aren't advertizing it heavily yet. but i think the core idea, which is to extend the scheme used by Part to actually do computations, is quite a nice one.
@Rojo I think so too. And I think the holy grail is static type checking, with full algebraic types being inferred automatically
@Rojo it would be based on "lower bounds", so that we warn on things that CANNOT be right, rather than complaining that something is ambigious
@Rojo and then of course we can use this to do compilation via LLVM, and suddenly we're on the same footing as Julia and Rust and C++. at least hypothetically.
This morning I posted a pseudo-answer saying I would post a long answer to a question providing there was an indication of interest. Somebody up-voted the pseudo-anwer, perhaps ironically, but still I'm embarrassed. Maybe, I shouldn't have made that post. Any opinions as to propriety of pseudo-posts?
@Szabolcs It is a package called TypeSystem` and it currently is used to model the type of data held by a Dataset. It's the beginning of a full algebraic data type description of data in Mathematica
@Szabolcs you can try it out by doing Needs["TypeSystem`"], and then you can things like RandomType[] and RandomData[type]. Also, there is TypeApply[func, {arg1, arg2, ...}] that does forward inference, and DeduceType[data] that infers the type of raw ata.
@m_goldberg In my view it's fine, especially given your disclaimer at the top. Everyone knows you're a valuable contributor here so I don't think there is any reason to be embarrassed. Personally I would either finish the post or delete it but I don't think it matters; if you leave it unfinished it will just sit at the bottom with fewer upvotes. No harm in that.
@mfvonh. No, not that. it's like someone was buying one those surprise sealed packages that go on sale often after xmas (reselling returned items). Don't understand why anyone will buy stuff sight-unseen. This feels like that and I wasn't asking for blind investment in a future answer.
What is the canonical way to test for the presence of a front end? Should I just check $FrontEnd === Null ? I need to test for this to make decisions about whether to use Dynamic in the output (to improve the user experience).
@Rojo I won't do the -> thing for mutating object state, it is indeed horrible. What I should think hard about is how to implement these interfaces in a concise and simple way (for future projects) and preferably avoiding mutable state completely. What I usually have is some sort of "physics" simulation written in C, which I want to control from Mma. Usually I want to made the simulation interruptable and resumable and the object I was talking about contains the simulation state.
A very important point is to keep things easy enough to implement so I can focus on the work rather than the implementation details.
Since everybody is asking stuff of @Szabolcs, I'll abuse his time a bit more :)
I've tried to work out how the time taken by ConnectedVertices scales with the number of nodes. I created a graph $n$ nodes and randomly connect either 10 of them or $n/10$ of them, and get the timings below:
(I did each many times so timings are fairly reliable)
it looks like a power law, which is reasonable, but there's a jump.
a) do you know offhand if it really is a power law? I guess it is b) any clue about the jump (again, offhand)?
@acl I may have to try myself. I am determined to get to the bottom of MrWizard's step function. So far I am mostly managing to demonstrate that it works rather than why in my tinkering
Since MapThread accepts a level specification, I think our ragged MapThread function should too.
raggedMapThread[f_, expr_, level_Integer: 1] :=
Apply[f, Flatten[expr, List /@ Range[2, level + 1]], {level}]
To solve the specific case posed in the question:
raggedMapThread[
Count[{##}, 0] &
