Page 1 of 1 [ 5 posts ]
 Print view Previous topic | Next topic
Yeti 6.2.2 released
Author Message
Yorick Guru

Joined: Wed Nov 24, 2004 12:51 pm
Posts: 98
Location: Observatoire de Lyon (France)
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
Yorick Guru

Joined: Sat Jan 22, 2005 2:44 pm
Posts: 86
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)

Wed Mar 26, 2008 8:53 am
Yorick Guru

Joined: Wed Nov 24, 2004 12:51 pm
Posts: 98
Location: Observatoire de Lyon (France)

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
Yorick Guru

Joined: Sat Jan 22, 2005 2:44 pm
Posts: 86

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
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)
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."

Thu Mar 27, 2008 9:05 am
Yorick Guru

Joined: Wed Nov 24, 2004 12:51 pm
Posts: 98
Location: Observatoire de Lyon (France)

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
Display posts from previous:  Sort by
 Page 1 of 1 [ 5 posts ]

#### Who is online

Users browsing this forum: No registered users and 1 guest

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

Search for:
 Jump to:  Select a forum ------------------ General    Announcements    Discussion & Support    Plugins    Bug Report