fdreerf wrote:

You might as well use the very flawed ln/e or log/10^ way, which is also really big and cumbersome.

What is wrong with

set [a^b v] to ([e ^ v] of ((b) * ([ln v] of (a))))

mlcreater wrote:

fdreerf wrote:

You might as well use the very flawed ln/e or log/10^ way, which is also really big and cumbersome.

What is wrong with

set [a^b v] to ([e ^ v] of ((b) * ([ln v] of (a))))

I don't think it's very accurate.

Maximouse wrote:

mlcreater wrote:

fdreerf wrote:

You might as well use the very flawed ln/e or log/10^ way, which is also really big and cumbersome.

What is wrong with

set [a^b v] to ([e ^ v] of ((b) * ([ln v] of (a))))

I don't think it's very accurate.

As far as I can tell, it works perfectly… as long as (a) is positive.

If it's negative or 0, then ln(a) is undefined, at which case you have to work a little harder with the workaround.

Za-Chary wrote:

Maximouse wrote:

mlcreater wrote:

fdreerf wrote:

You might as well use the very flawed ln/e or log/10^ way, which is also really big and cumbersome.

What is wrong with

set [a^b v] to ([e ^ v] of ((b) * ([ln v] of (a))))

I don't think it's very accurate.

As far as I can tell, it works perfectly… as long as (a) is positive.

…and as long as (b) is small.

That formula sets 3²⁷ = “7625597484986.977”

mlcreater wrote:

…and as long as (b) is small.

That formula sets 3²⁷ = “7625597484986.977”

I feel like that would be more of a “computers are inaccurate in calculating large numbers” problem rather than a “the math is wrong” problem. I'm not sure if an exponent reporter would fix that.

Za-Chary wrote:

mlcreater wrote:

…and as long as (b) is small.

That formula sets 3²⁷ = “7625597484986.977”

I feel like that would be more of a “computers are inaccurate in calculating large numbers” problem rather than a “the math is wrong” problem. I'm not sure if an exponent reporter would fix that.

It isn't a problem about large numbers, but one of precise numbers. Ln cannot be stored exactly in a float, nor can *e* or any noninteger log. e^ then amplifies the error again. For integer inputs, you may get better results using the log10 and 10^ reporters, not because 10 is anything special, (2 would be better) but because it's an integer, and *e* is not.

Remember that the error is only 0.033 anyway. If you were drawing that to the screen it wouldn't matter. If you knew the inputs were integers, you could round the result.

[url=redlink.com][color=red][u]red link[/u][/color][/url]

Za-Chary wrote:

mlcreater wrote:

…and as long as (b) is small.

That formula sets 3²⁷ = “7625597484986.977”

I feel like that would be more of a “computers are inaccurate in calculating large numbers” problem rather than a “the math is wrong” problem. I'm not sure if an exponent reporter would fix that.

JavaScript's Math.pow() returns the correct result (7625597484987).

space_elephant wrote:

It isn't a problem about large numbers, but one of precise numbers. Ln cannot be stored exactly in a float, nor can *e* or any noninteger log. e^ then amplifies the error again. For integer inputs, you may get better results using the log10 and 10^ reporters, not because 10 is anything special, (2 would be better) but because it's an integer, and *e* is not.

Remember that the error is only 0.033 anyway. If you were drawing that to the screen it wouldn't matter. If you knew the inputs were integers, you could round the result.

Indeed (though I don't think using log10 would help much because all logarithms are irrational but for those in which the input is the base raised to a rational power.) If you want the precise answer it shouldn't be too much trouble to use an integer algorithm. But custom reporters would really be convenient then…

It is actually possible to do non-integer powers of negative numbers accurately, without using Euler’s formula and whatnot. I made a project about it. One of the only cons is that you have to calculate a GCD.

support. It would be really useful, if they added sqrt why don't they add power?

drmcw wrote:

xlk wrote:

yes, but same can be said of the change x/y by and go to blocks… They aren't necessary, but for new scratchers are a great help.

Yes, but how many projects need a x^y block?

Seriously?! That is a suppppppper duper important function. You can use it for so many things: physics engines, platformers, so many things.

wangbolei wrote:

Seriously?! That is a suppppppper duper important function. You can use it for so many things: physics engines, platformers, so many things.

Ikr

(ツ::#000)//Master Kakawam, slays evil kumquats.

Another thing I'd like to point out is that adding the function would make Scratch more scalable. It would allow the freedom to do something like 2^x where x is a changing variable. There are workarounds but what if you're doing it within one giant mass of reporter blocks? It's harder to adapt your code because then you have to increase or decrease the amount of multiplying functions you have and it is also really confusing to deal with. If you say that that's not so, you may be thinking less complex or you may just be gifted with a natural ability to understand things. I'd say that I'm very able to pick things up quickly, I always have, but dealing with equations and theorems in Scratch can be a big pain. I'm no simpleton either (in the context of the majority on Scratch I'd say) I'm 16 in high school and I'd much rather solve a quadratic or a 3-variable system, which tend to leave a headache after, before I deal with things in Scratch. To give an example: the pythagorean theorem is a nightmare to work with currently. That is because you can't square your two values (a & b) so you need to multiply each by itself to do it. And on top of that, if you adapt it into the distance formula, you also have to do the subtraction bit again. I understand that the clutter caused by the many function reporter blocks is an issue that is inherent to the way Scratch's interface is made, there's no real getting around that fact. My hope with the implementation of this feature is that it reduces the clutter of many projects of more advanced nature (just projects that make use of equations where exponents are used). That will lead to more projects being less complicated-looking meaning that more people that view the code won't shy away from it because it seems too complicated. It will also make many equations more recognizable inspiring more creativity and also leading to more people wanting to understand why they used the equation in the project so that they try to understand the project and again, sparking creativity. Overall, I see the exponential function as a must-have tool for those who use mathematics in their projects. I would love to see this get added to Scratch in a future update, it's a must-have block really.

DrGaming_92Games wrote:

a super long post

Ikr more complicated programming languages like JS and Python all have this feature. And don't tell me that's too hard for very young people, there is already a block like this:

([sqrt v] of (9))
[] ^ []::reporter operators//So why not this block?

Edit: I found a workaround, but I don't think it's worth it and it only works for positive integers:

define (base)^(exp)
set[i v]to(base)//i is the result
repeat((exp)-(1))
set[i v]to((i)*(base))

(ツ::#000)//Master Kakawam, slays evil kumquats.

Support! This would be so much more convenient than having to use logarithms.

Workaround:

define (x) to the power of (y)
set [result v] to [1]
repeat ([abs v] of (y))
set [result v] to ((result)*(x))
end
if <(y)<[0]> then
set [result v] to ((1)/(result))
end

Seth_Zaw wrote:

Workaround:

define (x) to the power of (y)
set [result v] to [1]
repeat ([abs v] of (y))
set [result v] to ((result)*(x))
end
if <(y)<[0]> then
set [result v] to ((1)/(result))
end

thatisnotaworkaroundthatisnotaworkaroundthatisnotaworkaround we all know that that doesnt care about floats as y and please stop focusing on workarounds. theres some weird logarithmic stuff you can do but thats pretty inprecise.

4mat wrote:

Seth_Zaw wrote:

Workaround:

define (x) to the power of (y)
set [result v] to [1]
repeat ([abs v] of (y))
set [result v] to ((result)*(x))
end
if <(y)<[0]> then
set [result v] to ((1)/(result))
end

thatisnotaworkaroundthatisnotaworkaroundthatisnotaworkaround we all know that that doesnt care about floats as y and please stop focusing on workarounds. theres some weird logarithmic stuff you can do but thats pretty inprecise.

It's not that imprecise. The only problem is that it's pretty expensive to calculate decimal exponents of negative numbers.

support. I know the workaround with log is a thing but the very fact that this has logarithms feels like it should be enough to justify having an exponent/power block. It's a much more basic mathematical concept than mod/% or logarithms or many of the other things that the website has and as such the absence is just bizarre. I don't know that the question is so much “why should it be added” as “why isn't it added, when much more complex and… dare I say obscure… options are present?”

Also I'm sick of manually calculating powers of 2 for a hex/binary/decimal converter and I really don't want to drag out sixteen multiply blocks just to make it work

Maximouse wrote:

DarthVader4Life wrote:

noogai34 wrote:

No support. In Snap! the workaround is…

Script bars (result)
Set result to base
Repeat ((exponent)-(1))
Set result to result * result
End
Report result

result
Yes I was l a a y

this is scratch

It's Snap!. Scratch doesn't have a report block.

I think they meant that we are on Scratch, not Snap!