(I'll rotate the images... as soon as I can find how to do it with the Windows laptop that Martin gave me... ahhhh!! Where's GIMP when you need it?)
My family, books, photos, technology, language and some math משפחתי, ספרים, תמונות, טכנולוגיה, שפה, וקצת מתמטיקה
Wednesday, May 16, 2007
Some picture that I shot of Paris while attending XTech 2007
(I'll rotate the images... as soon as I can find how to do it with the Windows laptop that Martin gave me... ahhhh!! Where's GIMP when you need it?)
Tuesday, May 15, 2007
Priscilla Walmsley's tutorial on XPath 2.0, XSLT 2.0 and XQuery 1.0 on XTech 2007
I attended today a full day tutorial given by Priscilla Walmsley's on XPath 2.0, XSLT 2.0 and XQuery 1.0 on XTech 2007.
It was fun!!
Priscella is a very nice person and a very good presenter.
I learned a lot from her presentation and from the answers she gave to my numerous questions. I actually used her suggestion to ask questions freely and indeed asked a lot of them.
I found her book on XML Schema very useful both for designing XML Schemas and for insight of various "dark corners" of the (sometimes though to understand) XML Schema recommendation. And now after attending her tutorial, I think that I'll go ahead and buy her newly published book on XQuery.
I had some good luck to find Eric van der Vlist and Priscella Walmsley chatting together during the lunch break today. So I stepped in and introduced myself (which was not hard given the fact the I spent all morning in her class...). I had a good chance of describing some of the grief I was having with questions about XML Schema and that the only references other than the (sometimes) cryptic w3c recommendation are their books on XML Schema and the xmlschema-dev mailing list. They agreed. Then I asked them a technical question related to the namespace="##local" in an xsd:any in an XML Schema with no defined targetNamespace and non-qualified globally defined elements. It was a breeze for them to answer, and they also reasoned why and when this is useful.
I hope that I'll be able to talk with these two nice people again in the remaining days of this conference.
It was fun!!
Priscella is a very nice person and a very good presenter.
I learned a lot from her presentation and from the answers she gave to my numerous questions. I actually used her suggestion to ask questions freely and indeed asked a lot of them.
I found her book on XML Schema very useful both for designing XML Schemas and for insight of various "dark corners" of the (sometimes though to understand) XML Schema recommendation. And now after attending her tutorial, I think that I'll go ahead and buy her newly published book on XQuery.
I had some good luck to find Eric van der Vlist and Priscella Walmsley chatting together during the lunch break today. So I stepped in and introduced myself (which was not hard given the fact the I spent all morning in her class...). I had a good chance of describing some of the grief I was having with questions about XML Schema and that the only references other than the (sometimes) cryptic w3c recommendation are their books on XML Schema and the xmlschema-dev mailing list. They agreed. Then I asked them a technical question related to the namespace="##local" in an xsd:any in an XML Schema with no defined targetNamespace and non-qualified globally defined elements. It was a breeze for them to answer, and they also reasoned why and when this is useful.
I hope that I'll be able to talk with these two nice people again in the remaining days of this conference.
Sunday, May 13, 2007
Wednesday, May 9, 2007
Telecommuting improves productivity?
The following paper from career news says that evidence shows that telecommuting improves productivity. Read the fine-print in the paper.
More on managing your boss...
Lobbying your opinion upwards to your superiors is something that is worth doing, but only if you think you can do it well.
Here are a few things to note what you're trying to promote your opinions to your boss:
* find a common terminology -- be confident that your boss indeed understands what you think s/he understands. Gently try to say the same thing in more than one way, or from more than one perspective. This will help make your point clear.
* try to think like your boss -- you need to be able to explain why doing things your way actually makes your boss look better and helps your boss achieve his/her goals better than the alternative way(s).
* be flexible to change priorities dynamically as a response to signals that you receive from you boss: think like an investor: if you were investing money in this project, how would you see your money being well spent -- what actions would you expect be taken?
* think globally and do your best to see a bigger picture -- you might want to consider other perspectives to your opinion by trying to take another point of view, for example, what gives more value to clients, what can give a larger impact financially vs. minimum usage of resources (such as time, money, expertise...). Once you consider your issue from other perspectives and weight how they might look with your boss's glasses, you might either find more good reasons for your agenda or realize that your agenda has low probability to be accepted, and why.
* Quality makes a good argument -- if you can clearly and wisely argue that your agenda increases quality, it will give you extra credit. At the same time, though, you should always think how your suggestions to your boss can be validated after the act and that the criteria for success is clear and the means to measure the success is also clear. What I mean here is that you should not only strive to make good suggestions and be convincing -- for your credibility's sake, you also need to make sure that both you and your boss understand the criteria for success of your suggestion, that you both understand how this criteria should be measured and that you both understand the "hidden" cost of this validity of success. So -- quality has more than one side here: one is promoting your idea by reasoning how it contributes to quality, and the other is that you can articulate the means of demonstrating the quality of your work once its done.
* If you feel that there is resistance to your ideas, try to think why, try to understand the motivation for resisting your idea -- you might then find out that you can find reasons how what seems to be a limitation is actually a plus, or that the benefits outweight the disadvantages. As soon as you can fairly reason to yourself that you have good points to remove the resistance, you might want to think how you lobby it to your boss without marking yourself as someone who likes to argue for the same of argument and as someone who does not know how to take a no. Letting your boss think that it was his/her idea at the first place will many times prove useful -- it can remove a great deal of subjective resistance that mostly stemmes from personal ego...
You can read about some of these ideas and other ideas in a nice article "The Language of Success".
Here are a few things to note what you're trying to promote your opinions to your boss:
* find a common terminology -- be confident that your boss indeed understands what you think s/he understands. Gently try to say the same thing in more than one way, or from more than one perspective. This will help make your point clear.
* try to think like your boss -- you need to be able to explain why doing things your way actually makes your boss look better and helps your boss achieve his/her goals better than the alternative way(s).
* be flexible to change priorities dynamically as a response to signals that you receive from you boss: think like an investor: if you were investing money in this project, how would you see your money being well spent -- what actions would you expect be taken?
* think globally and do your best to see a bigger picture -- you might want to consider other perspectives to your opinion by trying to take another point of view, for example, what gives more value to clients, what can give a larger impact financially vs. minimum usage of resources (such as time, money, expertise...). Once you consider your issue from other perspectives and weight how they might look with your boss's glasses, you might either find more good reasons for your agenda or realize that your agenda has low probability to be accepted, and why.
* Quality makes a good argument -- if you can clearly and wisely argue that your agenda increases quality, it will give you extra credit. At the same time, though, you should always think how your suggestions to your boss can be validated after the act and that the criteria for success is clear and the means to measure the success is also clear. What I mean here is that you should not only strive to make good suggestions and be convincing -- for your credibility's sake, you also need to make sure that both you and your boss understand the criteria for success of your suggestion, that you both understand how this criteria should be measured and that you both understand the "hidden" cost of this validity of success. So -- quality has more than one side here: one is promoting your idea by reasoning how it contributes to quality, and the other is that you can articulate the means of demonstrating the quality of your work once its done.
* If you feel that there is resistance to your ideas, try to think why, try to understand the motivation for resisting your idea -- you might then find out that you can find reasons how what seems to be a limitation is actually a plus, or that the benefits outweight the disadvantages. As soon as you can fairly reason to yourself that you have good points to remove the resistance, you might want to think how you lobby it to your boss without marking yourself as someone who likes to argue for the same of argument and as someone who does not know how to take a no. Letting your boss think that it was his/her idea at the first place will many times prove useful -- it can remove a great deal of subjective resistance that mostly stemmes from personal ego...
You can read about some of these ideas and other ideas in a nice article "The Language of Success".
The Quit-Lag Phenomenon
I read an interesting articled titled "The Quit-Lag Phenomenon". What it basically says is that once an employee is set to leave a company, that employee can become very productive by doing things that seemed impossible or not so important before. This is due to removal of stress, concern of company politics, long term tasks etc. I don't want to write too many details of the paper, as you can read it yourself. What I do want is to give the punch-line, as I understood it:
By removing stress factors from your working environment and by taking care of details, you'll be able to be more productive and be able to address tasks that otherwise would seem intimidating. I think this is something worth trying.
By removing stress factors from your working environment and by taking care of details, you'll be able to be more productive and be able to address tasks that otherwise would seem intimidating. I think this is something worth trying.
Sunday, May 6, 2007
Friday, May 4, 2007
Wednesday, May 2, 2007
Iterating over permutations of a list
While trying to write down a Perl program that tries to generate XML instances given an XML Schema I stumbled upon the problem of generating instances of xsd:all subtree.
What xsd:all means, basically, is that the listed elements can appear in any order (elements that are listed in an xsd:all can appear 0 or 1 times exactly).
So, in order to do this, the problem reduces to Create an iterator that returns the next permutation of a given list. Why do I want an iterator?
Consider the following implementation:
The permute function receives a reference to a list, say, [ a b c ] and then it returns a list of lists, which is a list of all the permutations of the original list: [ [a b c] [a c b] [b a c] [b c a] [c a b] [c b a] ].
You can see that for a list with N items there are N! permutations.
Note that I'm not discussing lists that contain items that appear more than once. Those actually have less than N! permutations as disarranging places of similar items is meaningless. For example, the permutations of [a b a] are: [ [a b a] [ a a b] [b a a] ] because the remaining 3 permutations are the same.
Notice that the number of permutations grows rapidly as N becomes larger. This makes permute expensive.
We can try to do less calculations in permute by understanding that listing all permutations of two lists of the same length, say N, is actually listing the list of permutations for the list [0 1 2 ... N-1] and then mapping the elements to the proper positions. Combine this with a cache and we get a speedup whenever we want to permute a list of a length that was already computed before. Note also that once you permute a list of length N you also permuted lists of length 1 and of length 2 and so on up until N. So caching also helps when we want to list permutations of smaller lists than computed before.
Let's add a cache to the permute function:
Our cache is simply a hash. The key to the have is a serialization of the given list elements.
OK, now, but how do we map the elements back onto the list of permutations of indices? Consider the following code:
Which can similarly be implemented without the explicit loops using map:
So all you need now is to feed permute with 1 .. @list and then apply mapermute or permutemap on the result.
Still, I have a problem -- there are too many permutations, listing them is expensive, and not necessarily useful (I might not be able to read them all and use them all). It would be great if I could iterate over the permutations until I have enough, and not generate any permutation beyond the ones that I need. This requires a different approach.
I found a few ones such as:
http://www.perlmonks.org/?node_id=29374
and
http://www.perlmonks.org/?node_id=520116
and also
http://hop.perl.plover.com/announce/07
although the latter hides some of the magic only for subscribers.
You can Google for more results.
Now, let's try and see how to convert my recursion based solution into an iterator.
A colleague at work suggested I take a look at http://en.wikipedia.org/wiki/Permutation#Numbering_permutations
What we can learn from that link is basically:
Numbering permutations
Algorithm to generate permutations
So, let's see how this translates to Perl:
Surprisingly, for me, that is, if you iterate over from 1 up to N!-1 rather than up to N! the missing permutation will be the original list itself. I wonder if this is a general property of this formulation/solution and how to prove it.
See:
will produce all permutations, while iterating up to 5 will not produce [a b c].
I'm still pondering on what kind of refactoring is required in order to turn my recursive implementation into an iterative one, without using algebric tricks like the above mentioned implementation.
What xsd:all means, basically, is that the listed elements can appear in any order (elements that are listed in an xsd:all can appear 0 or 1 times exactly).
So, in order to do this, the problem reduces to Create an iterator that returns the next permutation of a given list. Why do I want an iterator?
Consider the following implementation:
sub permute {
my($list)=@_;
return [[]] unless scalar @$list;
my @permutations=();
for(my $i=0; $i<@$list;++$i) {
my @copy_of_list= @$list;
my $removed_list_element = splice(@copy_of_list,$i,1);
push(@permutations, map{[$removed_list_element,@$_]} @{permute(\@copy_of_list)});
}
return \@permutations;
}
The permute function receives a reference to a list, say, [ a b c ] and then it returns a list of lists, which is a list of all the permutations of the original list: [ [a b c] [a c b] [b a c] [b c a] [c a b] [c b a] ].
You can see that for a list with N items there are N! permutations.
Note that I'm not discussing lists that contain items that appear more than once. Those actually have less than N! permutations as disarranging places of similar items is meaningless. For example, the permutations of [a b a] are: [ [a b a] [ a a b] [b a a] ] because the remaining 3 permutations are the same.
Notice that the number of permutations grows rapidly as N becomes larger. This makes permute expensive.
We can try to do less calculations in permute by understanding that listing all permutations of two lists of the same length, say N, is actually listing the list of permutations for the list [0 1 2 ... N-1] and then mapping the elements to the proper positions. Combine this with a cache and we get a speedup whenever we want to permute a list of a length that was already computed before. Note also that once you permute a list of length N you also permuted lists of length 1 and of length 2 and so on up until N. So caching also helps when we want to list permutations of smaller lists than computed before.
Let's add a cache to the permute function:
{
my %cache;
sub permute {
my($list)=@_;
return [[]] unless scalar @$list;
my $key = join ',',@$list;
return $cache{$key} if exists $cache{$key};
my @permutations=();
for(my $i=0; $i<@$list;++$i) {
my @copy_of_list= @$list;
my $removed_list_element = splice(@copy_of_list,$i,1);
push(@permutations, map{[$removed_list_element,@$_]} @{permute(\@copy_of_list)});
}
$cache{$key}=\@permutations;
return \@permutations;
}
}
Our cache is simply a hash. The key to the have is a serialization of the given list elements.
OK, now, but how do we map the elements back onto the list of permutations of indices? Consider the following code:
sub permutmap {
my($original_list,$indices_lists) = @_;
my @list_of_lists;
foreach my $il (@$indices_lists){
my @l;
foreach my $i (@$il) {
push @l,$original_list->[$i];
}
push @list_of_lists,\@l;
}
return \@list_of_lists;
}
Which can similarly be implemented without the explicit loops using map:
sub mapermute {
my($original_list,$indices_lists) = @_;
return [ map { [map {$original_list->[$_]} @$_] } @$indices_lists ];
}
So all you need now is to feed permute with 1 .. @list and then apply mapermute or permutemap on the result.
Still, I have a problem -- there are too many permutations, listing them is expensive, and not necessarily useful (I might not be able to read them all and use them all). It would be great if I could iterate over the permutations until I have enough, and not generate any permutation beyond the ones that I need. This requires a different approach.
I found a few ones such as:
http://www.perlmonks.org/?node_id=29374
and
http://www.perlmonks.org/?node_id=520116
and also
http://hop.perl.plover.com/announce/07
although the latter hides some of the magic only for subscribers.
You can Google for more results.
Now, let's try and see how to convert my recursion based solution into an iterator.
A colleague at work suggested I take a look at http://en.wikipedia.org/wiki/Permutation#Numbering_permutations
What we can learn from that link is basically:
Numbering permutations
Factoradic numbers can be used to assign unique numbers to permutations, such that given a factoradic of k one can quickly find the corresponding permutation.
Algorithm to generate permutations
For every number k () this following algorithm generates the corresponding permutation of the initial sequence
:
function permutation(k, s) {
var int factorial:= 1;
for j = 2 to length(s) {
factorial := factorial* (j-1);
swap s[j - ((k / factorial) mod j)] with s[j];
}
return s;
}
Notation
- k / j denotes integer division of k by j, i.e. the integral quotient without any remainder, and
- k mod j is the remainder following integer division of k by j.
So, let's see how this translates to Perl:
sub permute {
my ($k,$s) = @_;
my @list=@$s;
my $factorial= 1;
local $[=1;
for(my $j=2; $j<=@list;++$j) {
$factorial*=($j-1);
my $i=$j-(int($k/$factorial)%$j);
@list[$i,$j]=@list[$j,$i];
}
return @list;
}
Surprisingly, for me, that is, if you iterate over from 1 up to N!-1 rather than up to N! the missing permutation will be the original list itself. I wonder if this is a general property of this formulation/solution and how to prove it.
See:
for (1 .. 6) { # 3! equals 6...
print permute($_,[qw(a b c)]),"\n";
}
will produce all permutations, while iterating up to 5 will not produce [a b c].
I'm still pondering on what kind of refactoring is required in order to turn my recursive implementation into an iterative one, without using algebric tricks like the above mentioned implementation.
Thursday, April 26, 2007
Independence Day BBQ
Wednesday, April 25, 2007
Becoming Your Own Boss
I read a nice articles titled "Becoming Your Own Boss" (https://origin.www.spectrum.ieee.org/print/5001 or see: https://origin.www.spectrum.ieee.org/apr07/5001).
I especially liked the advice to start with managing your boss :-)
I especially liked the advice to start with managing your boss :-)
Monday, April 23, 2007
Birds I saw in the park next door today
Subscribe to:
Posts (Atom)



