World: r3wp

In this case, I wrote most of those micro-optimizations in the last 
three years :)

I understand, but at the start of that, REBOL was a ten years old 
project, and a thirty years old design

Yes indeed. A lot of the improvements in R3 came from insight gained 
from many years of REBOL use.

By many people in the community, not just the R3 team.

It is just as easy in theory to write the code in micro-optimized 
form as it is to not, so why not?

So that's a "Yes" to my question then? ;-)

>> a: [a 1]
== [a 1]
>> a/:b
** Script error: :b has no value
>> select a 'b
== none

Brian, Are you kidding ? Could you avoid stupid code ? :-)

>> a: [a 1]
== [a 1]

>> b: 'c
== c

>> a/c
== none

>> a/:b
== none

Exactly the same behavior than SELECT, not more not less.

But I prefer the compact form, more readable IMHO.

Another old Idioms.
first serie
vs 
serie/1

I see that everywhere (even Ladislav use it too much ;-))
serie/1 is a lot faster though

Carl used to advise it was slower. Was that so in R2?

It's true, path notation slower with R2, not anymore with R3

A/1 is 2 time faster than FIRST A, on my config.

Actually, first calls pick

That's nice, I like that much better, and certainly more robust path 
evaluation

It's highly annoying to have paths bomb out instead of return NONE

We don't have that anymore since a while, both in R2 and R3.

>> b: []
== []
>> b/1
== none
>> b/a
** Script Error: Invalid path value: a
** Near: b/a

Was talking about the first form only (with the index)

but yeah

R3 is more lenient

Hasn't the first form always been like that?

Don't think so, but my memory is not that good :-)

Don't think so, but my memory is not that good :-)

I Remember something like: 
Hey ! You past the end !

At one point in R2, it was something like this:
>> X: [1 2]
== [1 2]
>> X/2
== 2
>> X/3
== none
>> X/4
!Error

(...well, for some reason I remember it that way, at least.  There's 
a chance I have it confused with something else...)

Steeve, you are right, I missed that :(

Gregg, my answer to your question is that writing micro-optimal code 
in the first place is usually not premature optimization; it is instead 
just avoiding having to rewrite as much of the code later. So it's 
still optimization, just not premature. Making macro-optimizations 
before you have the overall design done is usually premature optimization, 
but if your code style is consistent then you can make them later 
without having to rewrite too much, in my experience :)

Re "premature optimization" - I do not think I ever did have any 
feeling I used that. For example, I would never want to write O(n 
*n) code when O(n) is available, no matter how would anybody want 
to call my approach.

I posted a note on Geany as a possible linux rebol tool in IDE as 
Carl's Rebol Blog is no place for running notes - but altme cannot 
tag a topic ?  And trying to select a group here on linux as ALTme 
1.2.25 is loading is just a crap shoot - highlight and click and 
close yore eyes or is it the reverse?

Probably because AltME resorts the groups as you are trying to click 
the one you want, thus getting the wrong one.

We might want to change groups on the opimization topic. How about 
Performance?

Do we have NaN (Not A Number) defined in R3?

I don't think so. Is it needed?

This page suggests that the "internals" of R3 does have NaN defined 
http://www.rebol.net/wiki/Decimals-64but it doesn't appear to be 
accessible.

Related topic, Jerry: INFs (see comment from Carl, which perhaps 
offers some hope that the situation will be normalised one day):
    http://www.curecode.org/rebol3/ticket.rsp?id=1717

This page suggests that the 

internals" of R3 does have NaN defined" - how does the text suggest 
it? I, as a coauthor will try to correct the text, if it does.

Certainly, IEEE754 defines NaN, but Rebol does not need to use/define 
it in any way.

So, for Rebol decimals, NaN is not defined/supported at present, 
nor are there any plans to use it in the future.

Thanks for the answer, Ladislave.

(but, of course, if such a wish exists, there is always the possibility 
to put it as a wish to CureCode)

yes, put it in curecode. if it's rejected, at least there would be 
documentation of why it's rejected.

Do we know a reason why it is desirable to have decimal! NaNs?

Ladislav - The following sentence implies that there is an internal 
NaN:
 

The exponent value 2047 is reserved for overflow and NaN (Not a Number)

I wrote that, I think. I got it from a IEEE 754 definition, like
http://en.wikipedia.org/wiki/IEEE_754-1985

Think of that part of the text as a description of the floating point 
standard used by CPUs.

Maybe you can try
to-decimal #{ ... 16 digits ... }

If that still works, you can use it to test, what you get, when you 
construct numbers like NaNs. To see how REBOL3 handle it.

Just checked. That sentence is in the section named "IEEE754 standard", 
so it is OK.

The IEEE754 standard reserves such a value for NaNs, overflow, etc. 
But, that does not mean, Rebol has to implement those.

BTW, "reserved for X" does not mean "X is implemented", it just means, 
that it should not be used for other purposes.

Nevertheless, I would like to see some coherent reasons why to support 
NaNs in Rebol.

As far as I am concerned, I guess, that Carl felt that:

>> 1 + (square-root -1) / 2
** Math error: positive number required
** Where: square-root
** Near: square-root -1

is more comfortable, than

>> 1 + (square-root -1) / 2
== #[NaN]

could be