1 ACCEPTED SOLUTION
Accepted Solutions
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
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
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
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
Werner Exinger написал(а):
Random numbers have to be unitless by default.
It's like the old army joke.
The commander ordered the soldiers to dig a trench from the fence to the... dinner!
(Это похоже на старую армейскую шутку.
Командир приказывает солдатам копать траншею от забора до... обеда)
Werner Exinger wrote:
The problem, as already stated, is, that Prime does not throw an error when fed with units, but its perfectly in accordance with the docs, that the result of runif are unitless numbers.
We have to distinguish between bugs in Prime and features we would like to see implemented. Its sure a legitimate feature request that runif should also be able to handle units the way you expected it (though it would not be high up on my large list of requests). Have you already placed a product idea?
I suppose it depends upon what the scope of "the docs" is. PTC certainly continue with the Mathcad tradition of pointing out the utility of the built-in units, and it could be argued that there is a user expectation that anything that doesn't implicity handle units, should explicity reject them (eg, raise an error - as M15 does); certainly, mixed units should be rejected out of hand.
Perhaps the problem should be raised as both a behavioural and documentation bug, with the correct behaviour being the random number generators are unit-aware. 
Stuart
I was intrigued by Werner's calculation
And did a bit of investigating:
The function "UnitsOf" strips off any multiplier. Why the unit of volume is a kilo-liter mystifies me.
Richard Jackson написал(а):
Why the unit of volume is a kilo-liter mystifies me.
Liter is an unit of capacity (volume).
m^3 is an unit of length^3
It is different physical quantity!
