@Silvia @PatrickStevens Do you see any good reason for that implementation? ... it escapes me ...

@belisarius I believe there is a reason, but I can't say if it's good or not..

@Silvia Could you try to enlighten me? :)

@belisarius The one reason I can think of right now is SplitBy is really just a syntactic sugar of Split. lol

Ah I thought there is an operator form like SplitBy[testfunc], guess I'm wrong.

And now I see Split[lst, tf] is actually Split[lst, tf[#1]===tf[#2]&]. That's really not good... Maybe the coder just got lazy?

@Silvia I believe there should be a reason. It's too big a mistake to duplicate the computational effort just b/c of a lazy coder :)

@Silvia Definition:a lazy coder is one who could write "b/c" instead of "because"

@belisarius Being lazier is the motivation of scientific progressing!

@Silvia :D Of course!

@halirutan This is good, but what if the diagonal has Infinity on it?

@halirutan My first thought was something like this (though I used 1-IdentityMatrix[n]instead) - I couldn't see a way to make it play nicely with Infinity

@belisarius I see no good reason at all. It seems to me that I could write it better myself.

@PatrickStevens When I see these things, I really wish Mathematica were open source ...

@Szabolcs Or at least the syntactic-sugar functions. I don't mind the proprietary kernel and low-level functions like Plus and Association and Select, but things like SplitBy I would prefer to be open to inspection.

@PatrickStevens SplitBy is open to inspection. Needs["GeneralUtilities"]; PrintDefinitions[SplitBy]`

@Pickett Yes, sorry, by "open to inspection" I really meant… actually I'm not sure what I really meant. I think I really meant "open to public improvement", but of course I could always Unprotect SplitBy myself.

Maybe I meant "open to improvement Github-style"

@Szabolcs Then the obvious solution is to make two branches of the function

ClearAll[zeroDiagonal]

zeroDiagonal[m_?Developer`PackedArrayQ] :=
  SparseArray[{{i_, i_} -> 0}, Dimensions[m], 1]*m;
zeroDiagonal[m_] := ReplacePart[m, {i_, i_} -> 0];

mp = RandomInteger[100, {12, 12}];
mi = RandomChoice[Flatten[{Range[5], Infinity}], {10, 10}];

On["Packing"]
zeroDiagonal /@ {mp, mi}

(well to be sure you should try with ConstantArray[Infinity, {10, 10}], but it'll still work)

@OleksandrR. Does the viral nature of the GPL refer only to distributing binaries or also to distributing source code? Say, can I write code that uses a GPL'd library, license my own source code under BSD (meaning that people are free to life portions of it and re-use it without the constraints of the GPL), but distribute the whole compiled package under the GPL?

The point is that parts of my own code that do not rely on the library are free to reuse without the GPL's restrictions.

Hi @Szabolcs Did you figure out this problem at the end? I seem to have the same problem as you did forums.wolfram.com/mathgroup/archive/2011/Jun/msg00283.html

Using the code here

The BSplineCurve and BSplineSurface own the SplineClosed option, for instance pts = {{0, 0}, {1, 1}, {2, -1}, {3, 0}, {4, -2}, {5, 1}}; Graphics[{BSplineCurve[pts, SplineClosed -> True], Green, Line[pts], Red, Point[pts]}] So I would like to how to implement this option. My thought is appending the first point to the pts list, however, it generates a different curve from built-in BSplineCurve[pts, SplineClosed -> True]. Very appreciate it:)

@xslittlegrass No, I haven't managed to solve it. People told me at that time that they could not reproduce it on (64 bit) OS X. Do use the remote kernel strategies script by all means!

@Szabolcs yes, that is absolutely fine, except perhaps if it is the Affero GPL (which is rarely used but has extremely stringent conditions on it). However I would say that this situation may not turn out to be the most favorable for you; it is the same one that the BSD community is faced with now. If you don't mind that, then no problem.

BSD is completely (one way) compatible with the GPL, so there is no question that it is valid to do as you propose.

As long as it's the 2-clause (new) BSD licence, of course. The 3-clause one with the no-advertising clause is not GPL compatible.

@Szabolcs Yes, I do, and I found that the error seems to relate to the SSH port forwarding. Even I quick the kernel and restart, it gives me the same error. And the error only stops after I stop the ssh port forwarding.

@Szabolcs The package have been updated github.com/sakra/Tunnel

@Szabolcs And I raised a issue for that problem github.com/sakra/Tunnel/issues/2

All, I have created a new tag lazy-computations, since I think this topic deserves a separate tag. Any comments / suggestions for a better name?

lazy-evaluation?

Also, we're assuming a lot. When lazy evaluation is better implemented in the Wolfram Language, it might be called something different which is more marketable... like "extremely patient evaluation"

Like how memoization is refered to as: "Functions That Remember Values They Have Found"

or Anonymous functions are often refered to as "pure functions" in the documentation, even when they possibly have side effects

@Searke Thanks for the input. Re: lazy evaluation - this is a more broad term. I meant specifically computations which are done with some laziness component, which is more specific. We may have lazy-evaluation as well, as a separate tag. Re: more marketable - I don't think we have to stick to terminology used at WRI. I actually think that sticking to more general CS terminology will serve the community better.

@Searke The pure functions example you gave is very characteristic - it creates a confusion, because in Mathematica the term is used differently from the common understanding what pure functions are. Thoughts?

@Searke We can always change / rename the tag later, if / when there is an established term emerging in the company, or make a tag synonym

I was joking about the marketable name thing

@Searke But the choice between lazy-computations and lazy-evaluation isn't clrear-cut for me, although I personally probably prefer lazy-computations for what I meant to be tagged by the tag.

I'm not sure what the distinction being drawn is between "lazy-evalution" and "lazy-computations". I don't think it's really significant

when I think of this subject however, the word that comes to my head is "lazy evaluation"

@Searke lazy-evaluation would mean an entire consistent model of laziness, supported by the language. Also, in a sense, things like holding a piece of code and evaluating it at a later time would fit there too. By lazy-computations I mean a more narrow set of cases, where certain computations are done upon-request. Basically, more or less what Streaming is supposed to do, but not tied particularly to Streaming framework.

@Searke The reason I want to narrow this down is that all other types of lazy evaluation are usually just technical tricks used to solve a particular problem, rather than something that the asker may ask up front, using the tag.

@Searke Alternatively, one may introduce a general lazy-evaluation tag, and another one like out-of-core-computations, and then the tag I suggested would probably be more or less equivalent to using both these tags. This might be a better solution.

tbh, I think the distinction is probably too narrow. When I read "lazy computation" I assumed it was a kinda strange way to say "lazy evaluation". Someone would have to read about the difference. It isn't obvious from the name itself.

I think I like the latter idea. "out of core computations" is very understandable.

An idiot like me would label so many things "lazy computation" assuming it basically just mean "lazy evaluation"

@Searke To put it differently, lazy-evaluation to me sounds like a programming model supported by the core language, while lazy-computations sounds like a programming model that is possible to use, but that is not supported by the core language per se. E.g., Mathematica certainly supports lazy evaluation, but it doesn't (natively) support lazy computations.

Yeah. I tend to use lazy evaluation to mean either.

I think Spark is a good example of this

People (and me) often talk of Spark doing "lazy evaluation". It's just a framework.

I believe that phraseology is even used in the Spark's own tutorials

@Searke Yes, I'd probably call Spark a lazy-computations framework. Usually, lazy evaluation means in CS a very specific thing - a feature which may or may not be supported in the language. It is usually a language-level thing.

@Searke Like, there is no lazy evaluation support in Java (expecially prior to Java 8), but one can do lazy computations in Java, by writing a framework

@Searke The problem is that lazy computations may be useful even when they don't mean out-of-core computations - but just as a way to program in functional style where otherwise one would have to resort to some kind of imperative coding. Although probably, such cases can be also serviced by lazy-evaluation

@LeonidShifrin I agree with this. Lazy Evaluation is for me what Haskell does. If you use a function and discard its return value, Haskell will happily not even call your function at all.

And here it is very important to have pure functions because side effects will never happen if Haskell removes the whole function call.

Therefore, lazy computation is maybe more appropriate. To me out of core computation is harder to understand than something with lazy, but that's probably only me. I guess functions in Mathematica will anyway not be called OutOfCoreComputedList.

@LeonidShifrin From the pure practical way of viewing at this, it might become handy when I'm working with lists of memory-heavy elements. Then, a framework that lets me simple map my functions of a lazy list, where the framework takes care of allocating and freeing objects would be great.

@halirutan it is sort of funny that we still use this term from the 60s and 70s today

@halirutan Thanks for the feedback! These are subtle matters, and we should probably strike a balance between being precise in the sense of CS, and using the term that would be understandable for most people. But you've confirmed my feelings.

@halirutan This is what Streaming does, or, at least, is supposed to do

@OleksandrR. Hi @OleksandrR.! Do you know if there are more modern terms considered more appropriate nowadays? I am not aware of them.

@LeonidShifrin not that I'm aware of. I think it is the standard term.

@OleksandrR. It's funny. When you edit a comment, you can apparently make it appear after the one that was replying to it.

@LeonidShifrin doesn't show up that way here

@OleksandrR. Indeed. I reloaded the page and it was Ok. But on my page, it looked that way before reloading. This looks like a small bug in the SE comment engine implementation.

@LeonidShifrin apparently "external memory" or "massive data" are used somewhat, and "big data" seems a related term that is better known. But I think none of these is as clear in its meaning as "out-of-core", as anachronistic as it may be

@OleksandrR. Oh, I see, you meant the out-of-core part. I thought you meant the one related to laziness. I agree that somehow out-of-core is more clear that the others, because it tells about the method used (not everything in RAM), while the others are more vague.

@LeonidShifrin oh, sorry. I think that concepts like lazy evaluation are basically timeless, whereas obviously nobody uses core memories today. I also don't know of any alternative to lazy evaluation/computation, except maybe "deferred".

This just has to be a bug. Can anyone confirm and tag? I'm really disappointed with the state of most of the graph stuff. mathematica.stackexchange.com/questions/5618/…

I cannot remove edge weights, cannot even properly test whether the graph is edge-weighted because WeightedGraphQ gives True when the mysterious and apparently not very useful VertexWeight is set ... (btw the documentation example for VertexWeight sets graphics as weights ...)

WeightedAdjacencyMatrix and WeightedAdjacencyGraph use different formats (!) and this is all fine according to the last exchange I had with support. NeighborhoodGraph computes a graph layout which makes it much much slower than a naive user-implementation of the same, and it does all this without giving any indication to the user about what's happening. Again, this is normal and unavoidable according to support/the developer.

They introduced multigraphs apparently without much thinking, so now it's not possible to set separate attributes or weights for edges going between the same vertices, then this causes bugs in functions as simple as GraphDistance. Multigraphs are literally useless in Mathematica, they're only there to be able to say they have them, but unusable for any work.

Internal representations of graphs still get broken occasionally, making functions like IsomorphicGraphQ give wrong result. Deleting edges or vertices still breaks graphs and messes up properties, making it a risky operation. Don't ever try to delete parts of weighted graphs unless you're looking for trouble!

The whole Graph system is a big mess. I imagine something must be really wrong with the internal design.

@Szabolcs Really sorry to hear that. You are probably one of the most experienced Mathematica users, heavily working with graphs, which gives your opinion a lot of weight, in my eyes at least. I haven't used Mathematica Graph functionality for anything serious, but from a distance it seems that two of the main sources for these issues are mutability (statefulness) of graphs and the way how computations are entangled with presentation / layout.