Reply to topic  [ 5 posts ] 
Yeti 6.2.2 released 
Author Message
Yorick Guru

Joined: Wed Nov 24, 2004 12:51 pm
Posts: 97
Location: Observatoire de Lyon (France)
Post Yeti 6.2.2 released
I've just released Yeti version 6.2.2 which you can get at http://www-obs.univ-lyon1.fr/labo/perso/eric.thiebaut/yeti_download.html.

It is mainly a bug fix release; there are however new functions like rgl_roughness_* to implement regularization in inverse problems (for those interested in...).

For a detailed list of new features and bug fixes, look at http://www-obs.univ-lyon1.fr/labo/perso/eric.thiebaut/yeti_news.html.


Thu Feb 14, 2008 4:02 am
Profile WWW
Yorick Guru

Joined: Sat Jan 22, 2005 2:44 pm
Posts: 86
Location: Pasadena, CA
Post Yeti 6.2.2
Thank you for the Yeti release, Eric.
* h_next has been broken for a while
* Can't we just agree to define sinc(x) = sin(x)/x; (x!=0) :oops:


Wed Mar 26, 2008 8:53 am
Profile YIM
Yorick Guru

Joined: Wed Nov 24, 2004 12:51 pm
Posts: 97
Location: Observatoire de Lyon (France)
Post 
Do you mean that h_next is still broken? I've just checked the following and it wroked fine for me:
Code:
h = h_new(a="a", b="b", c="c", d="d", e=3.4);
for (k = h_first(h); k; k = h_next(h, k)) write, k, h(k);

Can you provide an example?

Your definition, sinc(x) = sin(x)/x is the unnormalized sinc function.
In signal processing (where sinc is the most useful) the sinc function is defined to be the normalized sinc function: sinc(x) = sin(pi*x)/(pi*x). Since in my existing code I use the normalized version, I will not change this.

What I can propose is to explicitly provide two other sinc functions: normalized_sinc and unnormalized_sinc, then in your functions you can locally define sinc = unnormalized_sinc or whatever best suits your taste.


Thu Mar 27, 2008 1:04 am
Profile WWW
Yorick Guru

Joined: Sat Jan 22, 2005 2:44 pm
Posts: 86
Location: Pasadena, CA
Post 
Ok, it looks like I need to re-read the documentation....

I started using hash tables in a very basic way: I have to deal with an outdated meta-data format (ascii [key=val].) It is (too) convenient to stuff the whole thing into a hash table. I rarely need to access it, and I can modify/edit/write it at will. The catch is that the keys are long and somewhat complex:

example:
> h_keys(h)
["dump antenna 3 motion compensated image","raw data bytes",
"filtering interferogram active", .... etc

The great news: it all works perfectly ....
as long as I don't try to iterate with h_next:

> for (k = h_first(h); k; k = h_next(h, k)) write, k, h(k);
dump antenna 3 motion compensated image F
dump antenna 3 motion compensated image
dump antenna 3 motion compensated image
ERROR (*main*) hash entry not found
WARNING source code unavailable (try dbdis function)
now at pc= 27 (of 43), failed at pc= 33
To enter debug mode, type <RETURN> now (then dbexit to get out)

> h("dump antenna 3 motion compensated image")
["F",(nil),(nil)]
> k="dump antenna 3 motion compensated image"
> h(k)
["F",(nil),(nil)]
> h_next(h,k)
ERROR (*main*) hash entry not found
WARNING source code unavailable (try dbdis function)
now at pc= 1 (of 14), failed at pc= 7
To enter debug mode, type <RETURN> now (then dbexit to get out)

What is a bit unexpected is that "h_next" does not behave like an iterator for "h_keys."

Off course, I understand that this was not the intended use of yeti's hash table, and that I need to find some time to find the source of the problem.

The "sinc" (with smile) remark was a bit "in jest." I have had my own (math) "sinc" function for a while. I get yours as a "bonus." :wink:


Thu Mar 27, 2008 9:05 am
Profile YIM
Yorick Guru

Joined: Wed Nov 24, 2004 12:51 pm
Posts: 97
Location: Observatoire de Lyon (France)
Post 
The code example also works with multi-word keys:
Code:
h = h_new(a="a", b="b", c="c", d="d", e=3.4, "a multi-word key", "hello");
for(k=h_first(h);k;k=h_next(h,k)) write, k+":", h(k);

So I am not able to reproduce the bug. Can you provide me a minimal piece of code which raise this bug?

BTW you have to understand that h_first/h_next only works as expected if you do not modify the hash table during the scan/iteration, in particular in the loop you must not delete keys nor create new ones (though you can change the values of existing keys) because this may change the ordering of hash table entries. The error message you get "hash entry not found" can only be returned by h_next when the precedent key is not existing in hash table. So I suspect that the problem is that, in the loop driven by the h_next iterator, you have deleted some entry in the hash table. If not then there is really a bug. If you want to iterate over the hash entries whereas changing the hash table, you must first use h_keys to get the list of keys and then loop ever this list:
Code:
s = h_keys(h);
n = numberof(s);
for (j = 1; j <= n; ++j) {
  k = s(j);
  ...;
}


Fri Mar 28, 2008 2:18 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 5 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.