Re: [fricas-devel] [BUG] r1976: Remove argumentless 'random'; pfo.spad

2016-10-16 Thread Waldek Hebisch
oldk1331 wrote: > > I discovered this bug while I am digging another one: > > Martin's orignal integral: integrate((a + b*x)/((3 + x^2)*(1 - x^2)^(1/3)), x) > fails. However integrate(1/((3 + x^2)*(1 - x^2)^(1/3)), x) succeeds > while integrate(a/((3 + x^2)*(1 - x^2)^(1/3)), x) fails: > > (1)

Re: [fricas-devel] random from IntegerNumberSystem

2016-10-16 Thread Waldek Hebisch
> > The document says: >random : % -> % > ++ random(n) creates a random element from 0 to \spad{n-1}. > > That is good if n is positive. What if n is negative? When n is 0 or negative then segment 0..(n - 1) is empty, so call is incorrect. > (2) -> random(-5) > >>> System erro

Re: [fricas-devel] Re: [BUG] r1976: Remove argumentless 'random'; pfo.spad

2016-10-16 Thread Waldek Hebisch
> > > 1) The default value for nn is incorrect, and nn is not > > updated after being used in K2Z. > > > > Actually, I think argumentless 'random' is a good idea. > > I misunderstood a little, my point is: > 1) The default value of nn should not be 1. > 2) We should use "1+random(nn)" in this cas

Re: [fricas-devel] random from IntegerNumberSystem

2016-10-16 Thread oldk1331
> Current definition means that for positive n you get exactly n > values, each with probablility 1/n. Your proposed change would > break this nice relationship. For people who can not read > between lines we could add phrase: 'Error if n <= 0.'. Then the signature for random will be awkward: PI

Re: [fricas-devel] Re: [BUG] r1976: Remove argumentless 'random'; pfo.spad

2016-10-16 Thread oldk1331
> AFAICS code using FSRED has design problem: due to random > choice we may reduce denominator to 0. I believe that > in such case we should restart computations using different > reduction. But current code just signals error (which is > definitely wrong). Yes, that should be the correct soluti

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

2016-10-16 Thread oldk1331
Use Functor category to abstract the 'map' function, to reduce the number of ')display op map', what do you think? -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

2016-10-16 Thread Bill Page
On 16 October 2016 at 22:12, oldk1331 wrote: > Use Functor category to abstract the 'map' function, > to reduce the number of ')display op map', what do > you think? > +1 -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To u

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

2016-10-16 Thread oldk1331
Bill, you were in the previous Monad discussion thread, what do you think of the Monad this time? -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

2016-10-16 Thread Waldek Hebisch
oldk1331 wrote: > > Use Functor category to abstract the 'map' function, > to reduce the number of ')display op map', what do > you think? We have more than 50 packages named '*Functions2' which implement 'map' between two domains. In principle they could use single signature from single categor

Re: [fricas-devel] Haskell, Functor, Monad, Maybe

2016-10-16 Thread oldk1331
> We have more than 50 packages named '*Functions2' which > implement 'map' between two domains. I am not suggesting replace those packages that deals with more than two domains. I'm talking about map : (S->S, %) -> % , where % has a parameter S There are about 15 map signatures like this. >