unnor wrote:

ixvizikil wrote:

hotcrystal wrote:

TheRealAL2009 wrote:

Yeah, but suppose it was:

3.2 ^ 5
= 3.2 * 3.2 * 3.2 * 3.2 * 3.2
= 335.54432 (exactly that, it's not rounded)

While scratch's e^5ln(3.2) workaround might give something like 335.5443199999…

You would have to do something more complex to find which decimal places are just floating point error. Maybe if you multiply it by ten, various numbers of times, then round it and check the difference to see how close the decimal part is to 0 / 1.

But that's a bit of a hassle.

It's called floating point imprecision, and unfortunately, there is no solution to that.

I think the problem is not that we have imprecision (I don't know if ST could even avoid them by using complex code),
but that it's complex to build (I don't know anything about log, so I wouldn't be able to code the workaround myself).

-2.45^-2.125 =

unnor wrote:

(#1480)

ixvizikil wrote:

hotcrystal wrote:

TheRealAL2009 wrote:

Yeah, but suppose it was:

3.2 ^ 5
= 3.2 * 3.2 * 3.2 * 3.2 * 3.2
= 335.54432 (exactly that, it's not rounded)

While scratch's e^5ln(3.2) workaround might give something like 335.5443199999…

You would have to do something more complex to find which decimal places are just floating point error. Maybe if you multiply it by ten, various numbers of times, then round it and check the difference to see how close the decimal part is to 0 / 1.

But that's a bit of a hassle.

It's called floating point imprecision, and unfortunately, there is no solution to that.

I think the problem is not that we have imprecision (I don't know if ST could even avoid them by using complex code),
but that it's complex to build (I don't know anything about log, so I wouldn't be able to code the workaround myself).

-2.45^-2.125 =

medians wrote:

unnor wrote:

ixvizikil wrote:

hotcrystal wrote:

TheRealAL2009 wrote:

Yeah, but suppose it was:

3.2 ^ 5
= 3.2 * 3.2 * 3.2 * 3.2 * 3.2
= 335.54432 (exactly that, it's not rounded)

While scratch's e^5ln(3.2) workaround might give something like 335.5443199999…

You would have to do something more complex to find which decimal places are just floating point error. Maybe if you multiply it by ten, various numbers of times, then round it and check the difference to see how close the decimal part is to 0 / 1.

But that's a bit of a hassle.

It's called floating point imprecision, and unfortunately, there is no solution to that.

I think the problem is not that we have imprecision (I don't know if ST could even avoid them by using complex code),
but that it's complex to build (I don't know anything about log, so I wouldn't be able to code the workaround myself).

-2.45^-2.125 =

?

bitmap_caketin wrote:

(#1483)

medians wrote:

unnor wrote:

ixvizikil wrote:

hotcrystal wrote:

TheRealAL2009 wrote:

Yeah, but suppose it was:

3.2 ^ 5
= 3.2 * 3.2 * 3.2 * 3.2 * 3.2
= 335.54432 (exactly that, it's not rounded)

While scratch's e^5ln(3.2) workaround might give something like 335.5443199999…

You would have to do something more complex to find which decimal places are just floating point error. Maybe if you multiply it by ten, various numbers of times, then round it and check the difference to see how close the decimal part is to 0 / 1.

But that's a bit of a hassle.

It's called floating point imprecision, and unfortunately, there is no solution to that.

I think the problem is not that we have imprecision (I don't know if ST could even avoid them by using complex code),
but that it's complex to build (I don't know anything about log, so I wouldn't be able to code the workaround myself).

-2.45^-2.125 =

?

You can't have negative bases unless you use my workaround.

hotcrystal wrote:

snip
It's called floating point imprecision, and unfortunately, there is no solution to that.

2 ** 3

Assycot243 wrote:

hotcrystal wrote:

snip
It's called floating point imprecision, and unfortunately, there is no solution to that.

JavaScript uses floating-point and if you try

2 ** 3

it will give you 8.

([]^() :: operators)

LuigiLasagna wrote:

100% agree

PLSSSS

([]^() :: operators)

unnor wrote:

Assycot243 wrote:

hotcrystal wrote:

snip
It's called floating point imprecision, and unfortunately, there is no solution to that.

JavaScript uses floating-point and if you try

2 ** 3

it will give you 8.

They meant being unavoidable for Scratch.

Assycot243 wrote:

unnor wrote:

Assycot243 wrote:

hotcrystal wrote:

snip
It's called floating point imprecision, and unfortunately, there is no solution to that.

JavaScript uses floating-point and if you try

2 ** 3

it will give you 8.

They meant being unavoidable for Scratch.

And one of the points of an exponent block is to make that not the case.

unnor wrote:

LuigiLasagna wrote:

100% agree

PLSSSS

([]^() :: operators)

But why?

Mimi-EEEEE wrote:

unnor wrote:

LuigiLasagna wrote:

100% agree

PLSSSS

([]^() :: operators)

But why?

Why NOT?

Mimi-EEEEE wrote:

unnor wrote:

LuigiLasagna wrote:

100% agree

PLSSSS

([]^() :: operators)

But why?

Why NOT?

purplebunny63 wrote:

Mimi-EEEEE wrote:

unnor wrote:

LuigiLasagna wrote:

100% agree

PLSSSS

([]^() :: operators)

But why?

Why NOT?

WHY NOT IS NOT A VALID REASON

robloxnoob27 wrote:

purplebunny63 wrote:

WHY NOT IS NOT A VALID REASON

it is :]

CuteRobot22 wrote:

However, the reasoning behind this suggestion is explained in the OP.

bitmap_caketin wrote:

CuteRobot22 wrote:

However, the reasoning behind this suggestion is explained in the OP.

They still aren't adding anything to the discussion