World: r3wp

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?

The stack layout has changed for typed functions arguments, but it 
is backward-compatible, so all your dialects should work with the 
new version (not tested yet).

For float!, you need to do an extra type-casting on the arguments 
pointer to convert it to typed-float! instead of typed-value!. You 
have an example of that in %red-system/runtime/utils.reds in _print 
function.

Oldes, could you please test your bindings with the lastest revision 
of float-partial branch? They should run fine now.

Continuing here, briefly:


When I'm tired, I usually stick to running "monkey tests" or button 
mashing and take notes for the next day if something crashes. :-)

I made just a quick test with blur effect and it works... cool:)

Great, let me know when your ImageMagic binding will be ready, so 
I'll add it to the list of existing bindings.

I maybe need Red instead of Bash! /Reading syntax spec

DocKimber: was this possibility discussed anywhere --- re: bash vs. 
rebol or red instead of bash?

Sorry! DocKimbel

I've skimmed the BNF doc at the red-lang site. It seems it is rather 
vague and unverified. I think maybe I need to build a Coco/R EBNF 
grammar and to check the grammar formally, for unabiguity and other 
grammar errors.

maybe Doc is actually using the PARSE dialect rather than proper 
BNF.

Re: bash... i thought about this a lot, i'm not sure you can come 
up with a decent dialect, though it would be possible to create a 
bash-like language with more rebol-like syntax and semantics.

The BNF doc was written by Rudolf Meijer and it it strict EBNF. I 
did only a manual checking of the grammar and found no issues. I 
have planned to model it in ANTLR, but never found the time.

it it
 => "it is"

strict EBNF
 => "strict BNF"

The grammar rules I wrote for Red/System expressions should also 
pass through a BNF loader (except for the first five definitions): 
http://static.red-lang.org/red-system-specs.html#section-5.1

Evgeny: Red/System is a bad fit for scripting, it is too low-level, 
you'll need to wait for Red for having a good alternative to Bash.

Doc - what' coming after floating point support? Are you moving to 
work on Red itself?

I have to fix the LibC starting and ending code, then I'll move to 
Red runtime to finish it and start Red's compiler.

I'll also continue to work on the shared library support for Red/System 
at part-time, during weekends. I would like to have it working for 
the conference in Netherlands in march.

Is there something like QUIT function already?

Yes, QUIT is already defined and needs an integer return code as 
argument.

#import [
	LIBC-file cdecl [
		quit-return: "exit" [  ; Exit program, returning status code.
			status		[integer!]
		]
	]
]

yes.. just found it in C lib as well... goot to know I can use the 
quit without it - I was missing the return code

btw... is there any reason that print does not add the LF automatically?

Yes, it is hard to come up with good names for "print-with-LF" and 
"print-without-LF" functions. ;-)

if you need an LF, you can just write: print [value lf]

What about prin and print? Or print and printn ?

It's not perfect, but at least, that way, we only need a single PRINT 
function (no need to remember other names like PRINTF, PRINTLN, PRIN, 
...).

PRINT/LF ?

PRIN and PRINT: that was my first choice, but users were pushing 
hard for not having PRIN.

PRINT/LF: no refinements support in Red/System, that will come in 
Red only.

I think it is better to have print with LF by default.. but ok... 
I must repeat myself that red/system is just a low level:)

I think that it would be possible to have the following:
	
	print value   				 ;; automatic line feed
	print [value value lf]			;; no autmatic line feed

Problem is it would confuse newcomers no end.

btw... if I do print float, I get result like: 100.00000000000000 
. I guess you know this issue.

By default, PRINT for floats maps to `printf ["%.14f" f]`, I guess 
the formatting string passed to PRINTF could be improved.

Since Red is related to REBOL, prin and print seem natural choices.

LF by default: sure, but the issue is coming up with a good name 
for PRINT without LF then. We already had a debate here about that 
a few months ago, and having just PRINT ended up being the less problematic 
solution (but it's not perfect I know).

I suppose "%14f" would avoid the extra zeros? (haven't checked the 
PRINTF docs).

What is wrong with PRIN? It's not more confusing than LF