World: r3wp

Do you have an unhandled choice in SWITCH? Rather than return an 
undefined value (since Red/System doesn't have none!) it triggers 
an error instead. Put in a default clause.

Of course if that's not the problem, never mind.

Right, the SWITCHes in POSIX.reds need default clauses. I need to 
see which signal is raised on Syllable that is not listed in ***-on-signal.

LibC init code: I need to have a deeper look in the init/exit libC 
routines first to see what's exactly happening there before wiring 
it in Red/System. I'll do that once I finish the current work on 
partial float support.

Kaj, I am doing very simple UI now using GTK based on your Doc-Kaj 
work.  It is totally adequate for what I need to do in the next month 
but after that I want to add value to my users with the range widget 
and some others such as Calendar.   I think they will allow me to 
build smaller more precise user interfaces quickly.

I have been looking for keyboard event handling in GTK with little 
luck. Is this gtk_key_snooper_install () how to detect Home,End, 
PgUp, PgDn keys?

I haven't looked into that yet, but I'll keep it in mind for the 
coming time

Are you using Red in production? That's exciting

and risky? :-)

I don't know of much that isn't risky these days

All of us in Red are forcefully steering towards production, so we're 
well aligned

Is it already possible to get input args (when I run the app from 
console)?

Yes, using system/args-count and system/args-list, see: http://static.red-lang.org/red-system-specs.html#section-12

Yes production use but not yet controlling nuclear warheads.   The 
fall back is to use the web based UI  ... now used for 2 years.  
But in 2012 the data entry requirements are being made more challenging. 
  I am planning to use GTK UI using a smaller UI surface area ... 
 looks like a good starter project in a high school course ... unfortunately 
I haven't been in high school in a few decades.

Better check the license ...some of them exclude the use for controlling 
nuclear weaponry

Kaj, you mentioned something about your Red repositories on announce. 
Is it possible to update all libs through one fossil repository now 
or do I still need to update each separately?

They're separate repositories, as they're separate projects for different 
libraries

However, Fossil remembers archives it has handled. You can do "fossil 
all ls" to see which it knows about and "fossil all pull" to update 
them

pull only syncs the archive database. You still need to go into your 
checkout and do "fossil update" to check out the updates, but you 
could do that off-line

Doc just tweeted about floating point support improvement - the list 
got updated - https://github.com/dockimbel/Red/wiki/Floating-point-support-todo-list

Doc - thanks for the update :-)

Good stuff

Doc, might be of interest to you: http://drdobbs.com/blogs/parallel/232301070

Yes it is, thanks. Good stuff for 64-bit Mach-o version. The GOT 
handling seems intricated in Mach-o, I will try to avoid the methods 
that involve fixups in code.

For the floating point format experts around: 


I am investigating the simplest and most accurate way to support 
floating point comparison by implementing an `almost-equal` operator 
in Red/System. Due to the intricacies of such task, I have selected 
the two algorithms that look the best to me:


1) Tolerance-based: http://realtimecollisiondetection.net/blog/?p=89

2) Ulp-based: http://www.cygnus-software.com/papers/comparingfloats/Comparingfloating point numbers.htm


Of course, in both approaches, there are some accuracy parameters 
to be set by the user to adjust the comparison formula (good defaults 
will be provided anyway).


Are there better algorithms or better implementations of methods 
1) or 2)?

I have x-posted that message to the Red ML also: http://groups.google.com/group/red-lang/browse_thread/thread/527afaf181eee8c7?hl=en

2) is now used in R3

Do you know if it uses the implementation from above link or a custom 
one?

ad 2) This seems to be dated, and new stuff by Bruce Dawson's here 
- http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

Well, the implementation may be dated, but the principle remains 
the same. Moreover, we use it for doubles, not for floats, but as 
said, the principle remains the same.

Well, I just pointed to the new stuff, can't comment on validity, 
as I don't understand  the topics discussed properly, so you might 
be right of course ...

Doc, the last part of your 2nd choise (the ulp-based) named "Comparing 
using integers" is the method, I would look at. It's simple and I 
would guess, performs well. Tests are needed to say, if the other 
methods are faster. Could it be CPU dependent, which is faster?

In order to implement the algorithm for doubles did you need to have 
64-bit integers available?

I guess, you could split the 64-bit in 2 times 32-bit. If the most 
significant 32-bits are the same, you do the comparison the the least 
significant ones. This should work.

*on* the

Is that assuming you can convert a double to two 32-bit integers 
or that you jsut split the 64 bits into 2x32 bits?

jsut -> just

No conversion, just split.


The IEEE float and double formats were designed so that the numbers 
are Òlexicographically orderedÓ, which Ð in the words of IEEE architect 
William Kahan means Òif two floating-point numbers in the same format 
are ordered ( say x < y ), then they are ordered the same way when 
their bits are reinterpreted as Sign-Magnitude integers.Ó

Thanks.

Pekr: the link you're giving is the exact same article I've pointed 
to in 2), it just have a left menu added for quicker navigation, 
but that's the same article. If I haven't just stopped on this algorithm, 
it's because of the initial warning at the beginning: 


This article is obsolete. Its replacement - which will fix some errors 
and better explain the relevant issues - is being crafted as a multi-part 
series


And from Dawson's blog: "Years ago I wrote an article about how to 
do epsilon floating-point comparisons by using integer comparisons. 
That article has been quite popular (it is frequently cited, and 
the code samples have been used by a number of companies) and this 
worries me a bit, because the article has some flaws. I’m not going 
to link to the article because I want to replace it, not send people 
looking for it." 


So it appears that there are some errors (probably some edge cases 
not handled properly).

It's not imo the same article, it is supposed to be a fixed one, 
where its author does not even want to point out to what you posted 
as 2) :-) But - that does not matter, what matters is, what works 
for you/Red :-)

ah, now I can see it. It's in the frame, my intention was to post 
link "here" URL, but cutted and pasted the wrong one ...

Th new fixed version of Dawson's article is split in a new series 
of blog entries: http://randomascii.wordpress.com/category/floating-point/


But, alas, he hasn't yet reached the point where he shows the fixed 
version of `almost-equal` function.

I did not take anything else than the principle (did not copy/use 
his code) to implement the comparison.

To Geomol: the speed should not be bad, but that is not the main 
reason why this approach is good.

Variadic and typed functions now support floats datatypes (float-partial 
branch).


https://github.com/dockimbel/Red/commit/331a50e8e5535ffec710e86c7f5f2704292fc433

BTW, math operations (+, -, *, /) have been implemented for floats 
(only float! / float! or float32! / float32!).

Remainder and modulo should also work, but untested. The meaning 
of these operators has been adapted for floats, remainder (%) will 
return a standard IEEE rounded remainder, while modulo (//) will 
return a floating point remainder.

That's really great!

How do 64-bits typed values affect the other typed values?