Forgot your password?
typodupeerror

Comment: Re:We dont realy need 8000x4000 with eye-tracking (Score 1) 331

I don't think lag would be any problem, small eye jitter would stay inside the same high-res window. For larger eye movements, the eye normaly need some time to recognise what it is looking at. If we first present the eye with a low-res image, and then 1/60 of a second later swap it out with a higher res version should'nt be noticable at all.

Higher fps is only needed to rerender based on changes in the scene. Especially in the periferial part of the eye where it trades resolution for better motion-detection, but current gpu-speeds are allready plenty for that. (100fps should be more than enough for everybody)

Comment: We dont realy need 8000x4000 with eye-tracking (Score 5, Insightful) 331

By using eye tracking, we dont really need to render the whole screen at high resolution.
We only need to render the part the eyes are looking at at high resolution

The ability of the eye to percieve high resolution is only limited to a very small area, and the brain fakes it by moving the eyes around.
By superimposing a small image with high dpi on top of a larger image with low dpi, we get a high resolution window into the larger image.
If this high res window follows the eyes around, the brain will percieve a large high resolution image.

Naturally for this to work, the smaller image has to be updated to show the same part of the scene that it is replacing.

This can also be used to emulate a high resolution screen by keeping an area your screen black, and using a projector to project the smaller high-dpi image on the black area.

Oh, and by the way. Remember this post and use it as prior art in case some troll patents "A method of simulating high resolution images by combining multiple images of different scales and resolution"

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 1) 158

by roemcke (#30373950) Attached to: ECMAScript Version 5 Approved

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.

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 1) 158

by roemcke (#30373198) Attached to: ECMAScript Version 5 Approved

Just some added comment...

Of course, Scheme is less specific than IEEE 754 when it comes to the behavior of inexact operations, so an implementation is more likely to surprise even a diligent programmer who knows the spec for the language.

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

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 1) 158

by roemcke (#30372842) Attached to: ECMAScript Version 5 Approved

Exact/Inexact is all about behavior ??

No, exact or inexact is an attribute of a data value.

(Under what conditions an operation returns an exact or inexact value is part of its behavior, but far from the only important area of behavior a specification is likely to be concerned with.)

Yes, "exactly"

I think most programmers -- whether or not they have read the IEEE 754-2008 spec -- are aware that rounding takes place with floating point numbers.

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

There are very few languages where rounding would be done on integers (or rationals, if the language supports them in the first place) with exact operations.

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

Of course, Scheme is less specific than IEEE 754 when it comes to the behavior of inexact operations, so an implementation is more likely to surprise even a diligent programmer who knows the spec for the language.

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.

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 1) 158

by roemcke (#30372368) Attached to: ECMAScript Version 5 Approved

I did not describe the problem all that well.

In the cases I mostly run into, the test is to update a GUI to match buttons the user pushed. The value 1.0 is actually mathematically correct and works when used, so replacing it with some other value or a non-numeric would break the code. What is wanted is a reliable test that says "the user pushed the 'set to 1.0' button and we should highlight it". Things like that. I can assure you that if you use approximately-equal or try to track this value in a parallel variable things break and become unreliable.

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.

What I would like to see is the compiler produce a warning only if the value being compared to is not a constant that can be exactly represented. So "x == y" might produce a warning, and even "x == .1". But "x == 1.0" does not produce a warning.

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

I don't like the fact that I have to turn off an otherwise useful warning because they don't understand how real software is written.

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

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 1) 158

by roemcke (#30371910) Attached to: ECMAScript Version 5 Approved

I can understand that so far as the internal (within the interpreter) representation, but it certainly needs to specify the behavior of numeric data types, which is most of either the 1985 or the 2008 version of IEEE 754 specifies.

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

While I agree with you that Scheme's numeric tower is a good basic approach to a numeric type system your description of Scheme's numeric system as having only two types, "exact" and "inexact", is incorrect. The Scheme specification (both R5RS and R6RS) specifies a nested tower of 5 types (number, complex, real, rational, and integer). Exactness is an attribute that a numeric value -- of any of the 5 types -- can have.

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

Further, that doesn't address the issue of behavior, only that of representation.

Huh? Exact/Inexact is all about behavior ??

Actually, there is a lot more that a programmer may care about, such as how data that has to be rounded to fit into the representation used is treated, and what control they have over how that is done. That's a behavior feature that is specified by a floating point spec, and its a point of difference between the different versions of IEEE 754 (since the 2008 version has an additional rounding mode.) They also care about what values can be represented exactly, since that affects the behavior of operations and whether the results are exact or inexact.

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.

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 1) 158

by roemcke (#30371062) Attached to: ECMAScript Version 5 Approved

In C I need to turn these warnings off. In perhaps 99% of the cases where the test is something like "x == 1.0" what is being tested is not "did the calculation result in 1". Instead the test that is really being done is "was the earlier statement that read x = 1.0 executed".

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.

Unfortunatly these warnings are unable to distinguish why the test is being done, and it makes programmers do some stupid things to turn off the warnings.

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.

Changing it to some approximatly_equal() function will actually break the logic, especially for a calculation that CANNOT result in 1.0 except by the direct assignment. This is NOT uncommon!

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.

So stop proposing ideas without actually seeing how things are done in the real world.

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

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 1) 158

by roemcke (#30369946) Attached to: ECMAScript Version 5 Approved

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.

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 1) 158

by roemcke (#30369372) Attached to: ECMAScript Version 5 Approved

Actually, 754r handles situations like these via exception flags. If large_num + small_num == large_num, then the "inexact" and "rounded" flags will be raised (possibly others, too; I haven't looked at this in a while), which the programmer can use to take some alternate logic.

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

It's certainly true that stupid programmers can use these tools incorrectly (or not use them), but isn't that true of any system? Sufficiently stupid programmers can defeat any countermeasures.

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.

Comment: Re:I can guess why IBM was pushing for IEEE 754r (Score 2, Interesting) 158

by roemcke (#30366348) Attached to: ECMAScript Version 5 Approved

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.

Comment: He forgets stupid programmers (Score 1) 849

by roemcke (#28473607) Attached to: Nielsen Recommends Not Masking Passwords

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.

Many people are unenthusiastic about their work.

Working...