| bio | website | |
|---|---|---|
| location | ||
| age | 27 | |
| visits | member for | 1 year |
| seen | yesterday | |
| stats | profile views | 326 |
|
2d |
comment |
Flat function with repeated sequence You mean something like adding the definition JoinH[a_, b_, rest___] := joinH[a, JoinH[b, rest]]? |
|
May 16 |
answered | Dynamic Updating CreateDialog Problem |
|
May 16 |
comment |
Dynamic Updating CreateDialog Problem In the first example you give, you can close the dialog. It just so happens a new one is created whenever you close an old one. You can notice this through the names changing in the output. In the second case, you forgot your Dynamic around CreateDialog if that was what you are asking about. Perhaps you are simply looking for CreateDialog[Dynamic@y] ? |
|
May 9 |
comment |
Conditionals slower than operators? I understand that you just delete the output, but why are you timing how long it takes to print 4000 numbers? If you have any sort of real usage, where you need to show the user 4000 numerical values you would never print them one at a time to the notebook. It seems like a very odd example. |
|
May 9 |
comment |
Conditionals slower than operators? What are you trying to accomplish? I'm assuming that the goal of your function isn't to print out 4000 numbers to the notebook, In that case you should provide a better example since almost all the time spent here is used by the print statements. |
|
May 9 |
awarded | Enlightened |
|
May 9 |
awarded | Nice Answer |
|
May 6 |
awarded | Yearling |
|
May 6 |
comment |
Refresh dynamic variable when used with Get I always figured that Update was intended to be used exactly in situations like this, however it doesn't seem to work. |
|
May 2 |
comment |
Instruct a Table to only evaluate until a condition is fulfilled In the general case you are not guaranteed that you can perform your limit test globally, and you are left in the situation that calculating the range of elements you would want to iterate is effectively the same as iterating them. Though for the model case given this is naturally not the situation. As for this case, I think the results will depend greatly on how large you make your table, and you didn't really make it all that large. |
|
May 2 |
comment |
Instruct a Table to only evaluate until a condition is fulfilled @LeonidShifrin Thanks, I've added a block to scope the variable, and I simply forgot the attribute. |
|
May 2 |
revised |
Instruct a Table to only evaluate until a condition is fulfilled added 13 characters in body |
|
May 2 |
comment |
Instruct a Table to only evaluate until a condition is fulfilled I've added a NestWhileList solution to my answer to show what I mean. The solution is much more concise, yet it still doesn't actually use any of the iteratively passed on results for anything other than book keeping. |
|
May 2 |
revised |
Instruct a Table to only evaluate until a condition is fulfilled added 489 characters in body |
|
May 2 |
comment |
Instruct a Table to only evaluate until a condition is fulfilled Well that really was my point. You don't need this particular recursion pattern, but you chose it as a method of collecting results and thus end up using a loop constructor not because it fits the problem but because it fits your chosen method of collecting results. This seems counter productive, at the same time if you really wanted a "functional" style solution you should arguably have used a fixed point iteration since you don't want a fixed number of iterations but a short circuit iteration, thus you should have used either FixedPoint or NestWhile not fold. |
|
May 2 |
revised |
Instruct a Table to only evaluate until a condition is fulfilled deleted 1 characters in body |
|
May 2 |
comment |
Instruct a Table to only evaluate until a condition is fulfilled In my opinion this seems like a very counter productive solution. Fold is used as the loop constructor, but not because it nicely fits the problem, rather you needed to build a heap of scaffolding around it to make it work. The typical use case of fold is a loop where each iteration depends on the output of the last, which is not the case in this problem, every iteration depends only on the state of the iterators, and the only problem to solve is how to allow short circuiting. |
|
May 2 |
revised |
Instruct a Table to only evaluate until a condition is fulfilled added 28 characters in body |
|
May 2 |
answered | Instruct a Table to only evaluate until a condition is fulfilled |
|
May 2 |
comment |
Cusom PopupMenu file selector @halirutan Thanks for correction, it should be system independent now. |