Skip to main content
ValeryOchkov24-Ruby IV
24-Ruby IV
April 24, 2016
Solved

Runif etc functions and units - a bug?

Is it an error in Prime?

LucMeekesAnswer
23-Emerald V
April 24, 2016

I see no reason why random numbers should 'have to be unitless by default'...

If I want to define a set of random lengths, I'd like to be able to define them directly (Valery's method) rather than through a clumsy method. I think the present present implementation should be corrected in that sense, considring that the units in the arguments are accepted.

So, if the user provides (consistent) units for the arguments of the runif function, the result should have (the proper) units.

And about consistent:

Why are cm and m incompatible?

Luc

View in thread

11 replies

Werner_E
Werner_E25-Diamond I
25-Diamond I
April 24, 2016

Random numbers have to be unitless by default. To achieve this, Prime automatically divides the arguments by UnitsOf(..). This explains the effects you are experiencing.

Prime's help does not promise, that runif will return values with units.

So the correct way of doing it is V:=runif(10, 165,190) cm.

Its not clear to me why Prime accepts arguments with units anyway (Mathcad consequently throws an error).

Prime's help clearly states that that the syntax is runif(m,a,b) and that a and b are real numbers (a <b). So you can't call it a bug unless you want to call it a bug that prime accepts units and repairs that user error by its division by UnitsOf(..).

In Prime you may even mix different dimensions, which does not make any sense at all.

To clarify:

WE

Translate
LucMeekes23-Emerald VAnswer
23-Emerald V
April 24, 2016

I see no reason why random numbers should 'have to be unitless by default'...

If I want to define a set of random lengths, I'd like to be able to define them directly (Valery's method) rather than through a clumsy method. I think the present present implementation should be corrected in that sense, considring that the units in the arguments are accepted.

So, if the user provides (consistent) units for the arguments of the runif function, the result should have (the proper) units.

And about consistent:

Why are cm and m incompatible?

Luc

Translate
Werner_E
Werner_E25-Diamond I
25-Diamond I
April 24, 2016

LucMeekes wrote:

I see no reason why random numbers should 'have to be unitless by default'...

The reason simply is that this is what the help (the only "documentation" we have in Prime) implies.

If I want to define a set of random lengths, I'd like to be able to define them directly (Valery's method) rather than through a clumsy method. I think the present present implementation should be corrected in that sense, considring that the units in the arguments are accepted.

So, if the user provides (consistent) units for the arguments of the runif function, the result should have (the proper) units.

Thats a legitimate feature request and I have tons more of them. 😉

All I said was, that the behavior Valery is experiencing is consistent with the "docs" (aka help). So it can't be considered a bug. Its as it was intended - arguments to runif should be reals and that means no units. The problem arises because Prime (on contrary to Mathcad) accepts units and so we tend to expect units in the result. Prime should rather either throw an error or, as a new feature, work as expected.

> Why are cm and m incompatible?

Thats the difference between Round and round. Look at the docs/help file. Its poorly documented as is the rest of Prime, but its there.

The error message is wrong as "round" will not accept any units at all, just reals. And the optional second argument has to be an integer (of course unitless) meaning the number of decimal places.

"round" will only accept unitless numbers, but "Round(z,y)" returns round(z/y)*y, and z/y is unitless, if the units of z and y are consistent - the multiplication with y adds the proper unit factor to the integer result.

R

Translate
Terms & ConditionsAccessibility statement