All I understand is that you want x=1.0 to mean two things: "the value is 1.0" and "The button has been pressed". In c you can not this without comparing two floating point numbers with each other.

In a dynamically typed language you can do it the way you want with this pseudo-code (in case you didn't understand my scheme example):

void push_button()
{
    x = 1; // x is now an integer
}

bool test_for_buttonpress()
{
    if (! is_integer(x))
        return false;
    if ( x == 1)
        return true;
    else
        return false;
}

The x==1 in the above example never compares two floating point values with each other, even if x is sometimes set to a floating point value.

That is why i don't think the equality operator for floats is necessary in a dynamically typed language.

Just some added comment...

That is the whole point.. By being less specific than IEEE 754 on the behavior of inexact operations, Scheme can run efficiently on CPUs with a different floating point implementation.

I am sure the IEEE 754 is a fine standard, I have only read part of it and it was a long time ago so I don't remember much, but those thing I do remember were mostly good.
Implementors of compilers and interpreters need to know how inexact operations behave on the CPU. So if IEEE 754 define every detail of those operations, and CPU manufacturers implement IEEE754, then that is a good thing.

On the other hand, most users of high level langages, like Scheme and ECMAScript, doesn't care if the behaviors of inexact operations are predictable according to a specification they have never read. They want the operations to be exact in a predictable manner, for any number they might type on the keyboard, just like Scheme does, and ECMAScript currently doesn't

Yes, "exactly"

A lot of them do, but far from everybody. I have seen a lot of abuse of floating point numbers. People using floats as array indexes, monetary values or using the exponential function for bit-shifting (Ughh..)

Yes, and Scheme do support exact rationals. And if Scheme can do do it then i think ECMAScript should do it. It is in my opinion the best way to solve the 0.1+0.2 != 0.3 problem

Maybe, but when using inexact numbers and operations in Scheme, it is obvious to any programmers that there might be surprises. So by definition, any surprise is not a surprise. Luckily you have exact numbers and operations that can handle numbers with fractional parts, so inexacts aren't really needed for most programmers.

Then, in my opinion, you should define a compound variable "struct {x, highlight};" with a public interface that sets x and keeps track of the highlight flag. Using magic numbers in variables that normally hold scalar values is a documentation nightmare.

But how can the compiler know that you are not comparing 1.0 to something that you think is exactly 1.0 but is only almost 1.0?

In Scheme you would be able to do this, it is still ugly code though:

(set! x 0.9) ; Not magic number, a float
(set! x 1) ; Magic number, not a float

(and (exact x) ; Test for magic number
      (= x 1)) ; without doing comparisons between floats

It is my impression that most warnings are there because they do know how real software is written

Agree, as long as the behavior doesn't force a specific implementation and it is a sane behavior.

I am aware of that, but sometimes you have to simplify things to make them fit in a slashdot comment :-)

Huh? Exact/Inexact is all about behavior ??

And that is why Scheme is a good specification. Very few programmers have read the IEE754(r) specifications and understand when and how numbers are rounded or are even aware that rounding is taking place.

On the other hand the Scheme specification is simple to understand, and will give you very few surprises. Any integer or rational number can be represented exactly, and by sticking to "exact" functions, the results will also be exact. No need to care about how rounding is done, because there is none. Rounding of exact numbers will only take place when explicitly told so, in a way chosen by the programmer. When working with inexact numbers, only an implementation-specific precision is guarantied.

But what if the calculation did result in 1? Better to use a flag, or if you don't want to use a flag: x = -1.0 and test for x < 0.0 (assuming the calculation will always return positive numbers). Or even better: x=Nan, this has the nice effect that you can't use x in calculations unless it has been initialized.

Now, since Scheme (and ECMAScript) is dynamically typed, you are not restricted to use floating point numbers as magic markers in variables that normally hold floating point numbers. So doing what you proposed in those languages is both unnecessary and counter-intuitive.

If you turn off warnings, at least you were warned when thing breaks. That is better than having things that break and a lot of programmers doesn't understand why.

I agree, implementing an approximatly_equal() function is in many cases totally moronic, and mostly done when float/double is the wrong datatype to use.

Luckily, Scheme has a datatype called "exact" that can hold fractional values, can do arithmetic without rounding errors, and comparisons for equality do make sense. This can be used most places where float or double is wrongly used now, and is why I used Scheme as an example of how things can be done right.

I have seen a lot of things done in the real world, both good and bad. That is why I propose ideas

I am not saying that ECMAScript should choose the old IEEE 754 standard in favor of the new 754r. What I am saying, is that the ECMAScript standard should specify neither of them. It is up to the implementation to select a numeric representation that makes sense on the CPU it it is running on, just as most other programming languages are doing.

I am also fully aware of that in many applications it is important that 0.1+ 0.2 equals 0.3. That is why I used Scheme as an example of how it can be done right. By calling a datatype "inexact" in stead of float/double, it is quite obvious for most programmers that it should not be used for exact calculations. And the "exact" datatype is not limited to holding integer numbers, perfect for counting dollars and cents.

As long as a programmer is not parsing/serializing binary data, all he cares about is whether calculations are exact or inexact, not if they are using the 754 or 754r internal representation.

Will these be accessible from ECMAScript? And will most programmers use them correctly?

Exactly, and that is why i think 754r is a stupid hack. Depending on it makes implementations more complicated without solving the problem it is set out to solve: Programmers that haven't done their homework.

Having two numeric datatypes, exact and inexact, won't totally solve "the stupid programmer bug" either, but it will make it much easier for most programmers to understand what is going on, and do the right thing. And it will have the added benefit of letting the language implementation choose the right approach for internal numeric representation for the CPU the interpreter is running on.

So 754 vs 754r boils down do this: When doing arithmetic using 754, then 0.1+ 0.2 != 0.3 (as any half decent programmer should know). IBM want to fix it with a new floating point format that can do exact calculations (under certain circumstances) with decimal numbers.

Personally a see two problems with this:

First, it won't fix the stupid programmer bug. 754r can't guarantee exactness in every situation. For instance, (large_num+small_num)+small_num == large_num != large_num+(small_num + small_num).

Second, ECMAScript is supposed to run on different architectures. It should not depend on specific number-representaions, not for integers and certainly not for floating points.

In my opinion, the right thing to do is to look at Scheme. Scheme has two numeric types, exact and inexact, and leaves it to the implementation to choose what internal representation to use (normally integer or some rational number for exact numbers, and floating point for inexact). If a function can can make an exact calculation with exact numbers as input, it returns an exact number, otherwise it returns an inexact number.
The important here is that when the programmer needs exact calculations (for instance monetary calculation with fractional parts), he specifically chooses exact numbers and leaves it to the language-implementation to figure it out how to represent the numbers in memory.

There is only one minor problem with the scheme-way, it doesn't discourage the use of inexact numbers when it is obvious that the programmer is a moron. An improvement for both ECMAScript and Scheme, could be to throw an exception whenever the programmer compares two inexact or floating point numbers for equality.

Security never ever works if the attacker and the one being attacked is the same person

Normal text-entry widgets and password boxes have different usability and security requirements. For instance, you don't want your webrowser to show a dropdown list of all your passwords as plain text. As soon as both widgets look mostly the same you can be quite sure half of the website programmers out there starts using the wrong widget.

They don't expect people to buy stuff at those prices. The prices are high so that they can pressure OEMs into making shady deals.

I don't know if GSM phones check with a database to see if they are allowed to connect to the access point when listing networks.

What is claimed in the patent is doing ALL of the following in a single product:

- Scanning for access points or looking them up from a storage medium
- Looking up access rights for the access points from a database
- Listing access points to the user, where access points belonging to the same provider are shown as a single item.

Some claims ar more specific, but i think doing only 2 of the 3 things above should not count as infringement or prior art.

Disclaimer: My knowledge of patent law is by reading slashdot. And patents are generally harder to understand than obfuscatet perl-scripts.

I hope they get this patent and start going after patent trolls. Often pantents are aquired for defensive purposes, so that you can countersue if somebody sues you. Normally patent trolls doesn't produce any products, so there is no way to sue them for patent infrigment to protect yourself, except if you own a patent for abusing the patent system :)

Instead of using a different url for handhelds, why not use a customized CSS together with the "handheld" media type?

See http://www.w3.org/TR/CSS2/media.html

Having two different urls for the same content, but for different target devices breaks the concept of linking. Google and other webpages linking to Wikipedia can not know (and should not know) what kind of device the users have.